[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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]