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