Re: git log -> changelog

[Peter Rosin]

Den 2010-09-06 11:27 skrev Gary V. Vaughan:
> On 6 Sep 2010, at 12:47, Ralf Wildenhues wrote:
>> * Gary V. Vaughan wrote on Mon, Sep 06, 2010 at 05:20:30AM CEST:
>>> On 6 Sep 2010, at 03:44, Ralf Wildenhues wrote:
>>>> Except that the autotools project logs contain lots of S-O-B entries
>>>> which explicitly do not have that particular meaning.  :-/
>>>
>>> I suppose we can create an annotation for logs that have a non-compliant
>>> SoB as if it was any other commit log typo we want to override to make
>>> sure gitlog-to-changelog creates a beautiful ChangeLog -- after we document
>>> our policy, and for entries going back to the beginning of the year in
>>> which we decide to start using gitlog-to-changelog.
>>>
>>> Even if we wait until next year to start using gitlog-to-changelog, I
>>> think it worthwhile to know in advance how we will cope with a commit log
>>> that needs a correction.
>>
>> Definitely, yes.  I'm afraid I still don't quite understand the intended
>> semantics though.  All S-O-B entries are to be co-authors of the patch,
>> starting from, say, January 1, 2011?
> 
> As a start, yes.  We also need to come up with a way to annotate for
> `(tiny change)', and to override typos without changing history.
> 
> And then we need to patch gitlog-to-changelog so that it produces correct
> ChangeLog entries when it encounters those annotations.
> 
>> I wonder whether it makes sense to ask for a more consistent notation
>> upstream, or push for one.  It'd be nice if gitk, cgit, and the like,
>> could also display things as intended.
> 
> That would be very nice!
> 
> Before we can pursue any of that though, we might like to fiddle with
> gitlog-to-changelog and add appropriate annotations to the 2010 Libtool
> commits to ensure we can rebuild our current ChangeLog from the git
> commit logs.
> 
> Really, I'm just throwing that all out there so it isn't forgotten... I
> have plenty of unfinished patches backed up on the use-gnulib branch
> already to be able to tackle anything else in earnest until a few weeks
> after the release at the earliest.

How about a commit hook that grabs the commit message, prepends the
date-author-email blurb in ChangeLog format (if not the same as the
previous commit), indents the message with a tab and strip S-O-Bs and
other git stuff. But only if there are no changes to ChangeLog in the
first place. Then you could do all the fiddling when needed by
providing a prewritten ChangeLog entry. Hmm, but that would not work
for ammended commits etc.

Just an idea...

Cheers,
Peter