Re: gitlog-to-changelog

[Jim Meyering]

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.