[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gitlog-to-changelog
From: |
Jim Meyering |
Subject: |
Re: gitlog-to-changelog |
Date: |
Tue, 17 Jan 2012 19:23:08 +0100 |
Joel E. Denny wrote:
> On Sun, 15 Jan 2012, Akim Demaille wrote:
>
>> Le 13 janv. 2012 à 12:00, Jim Meyering a écrit :
>
>> > What do you think about generating ChangeLog from git log like
>> > we do for coreutils, grep, gzip, diffutils, etc.?
>>
>> I am personally very much in favor of it. But I'd like to be
>> sure that Joel is too (hi Joel, happy new year!).
>
> Thanks for asking, Akim. Now that gitlog-to-changelog has --amend, I'm
> much more interested in using it.
>
> However, I still dislike that gitlog-to-changelog sometimes merges
> adjacent log entries that have the same date and author lines.
I made it work that way because that is precisely how Emacs's changelog
mode works.
However, I found that behavior misleading in the presence of multi-paragraph
ChangeLog entries. In that case, the normal same-say-same-committer
commit-delimiter (a blank line) is also part of a commit log. Oops.
Thus, the default is now *not* to merge any commit log entry with two
or more paragraphs.
> Aesthetically, I find this practice inconsistent. Practically, I find it
> unhelpful (what is the value of this complication?) and potentially
> confusing (in the case that someone has a source tarball and notices a
> ChangeLog entry for which he'd like to find the corresponding commit in
> git).
I don't follow the above. How does grouping commits done by the same
person and on the same day in one date-delimited block in a ChangeLog
hinder archaeology? AFAICS, no information is lost.
> Jim, I recall there was some recent discussion about all this on
> other mailing lists, and I've probably just recapped that here. What was
> the conclusion?
I didn't see the need for a new option (so didn't write it)
and no one volunteered a patch.
> Also, how is gitlog-to-changelog intended to behave at merge commits?
I haven't thought about it, or even tried it, yet.
> For example, does it follow all parent commits or just the first? Does it
> print the merge commit itself? Sorry, I haven't taken the time to try it
> out. I'm just thinking of an old discussion about how bison.git might one
> day adopt the strategy of merging lower-numbered release series branches
> up to higher-numbered ones. Currently, we just cherry-pick both ways,
> keeping the logging issues simpler.
>
> That brings up another question. I cherry-pick with -x, which adds
> helpful info to the git log that's not interesting in the ChangeLog. Is
> there any automated way for gitlog-to-changelog to drop that info? (For
> example, --amend could support perl code that applies to all entries.)
I'm really not that concerned with what the final ChangeLog looks like.
Any serious archaeology will involve using git directly.
- [PATCH] build: avoid warning from coverity about lbitset_elt_find, Jim Meyering, 2012/01/12
- Re: [PATCH] build: avoid warning from coverity about lbitset_elt_find, Paul Eggert, 2012/01/12
- Re: [PATCH] build: avoid warning from coverity about lbitset_elt_find, Jim Meyering, 2012/01/13
- Re: [PATCH] build: avoid warning from coverity about lbitset_elt_find, Akim Demaille, 2012/01/13
- Re: [PATCH] build: avoid warning from coverity about lbitset_elt_find, Jim Meyering, 2012/01/13
- Re: [PATCH] build: avoid warning from coverity about lbitset_elt_find, Akim Demaille, 2012/01/15
- Re: [PATCH] build: avoid warning from coverity about lbitset_elt_find, Jim Meyering, 2012/01/15
- gitlog-to-changelog (was: Re: [PATCH] build: avoid warning from coverity about lbitset_elt_find), Joel E. Denny, 2012/01/17
- Re: gitlog-to-changelog,
Jim Meyering <=