Gary V. Vaughan skrev 2011-10-31 16:36: > Hi Peter, > > On 31 Oct 2011, at 22:24, Peter Rosin wrote: >> Gary V. Vaughan skrev 2011-10-23 18:17: >>> We already have to enter all the ChangeLog relevant information into the git >>> commit log. Instead of worrying about keeping them all in sync, this patch >>> generates the current year ChangeLog from the git logs using a gnulib >>> script. >>> At the beginning of the year, we can still rotate it out into ChangeLog.2011 >>> and let the script carry on generating next years ChangeLog. >>> >>> It would have been even better to generate all of the ChangeLogs on demand, >>> but the formatting differences and missing logs for many of our historic >>> commits dating back to CVS especially look awful, so this is a good >>> compromise >>> between making maintenance as low-friction as possible and having ugly >>> unreadable >>> early ChangeLogs. >>> >>> I'll push in 72 hours, pending review comments in the mean time. >>> >>> * ChangeLog: Removed. >>> * HACKING (Editing 'ChangeLog'): Removed. Renumbered other sections to >>> compensate. >>> * bootstrap.conf (gnulib_modules): Add gitlog-to-changelog. >>> * Makefile.am (ChangeLog): Generate the ChangeLog for 2011... >>> (dist-hook): ...from the output of `git log' before rolling a >>> distribution tarball. >> >> Sorry for the late response, > > No worries :) > >> but *all* relevant info from the ChangeLog is >> generally *not* included in the git commit message. E.g. commit 72266fce >> "docs: improve description of -no-undefined." where the mention of >> co-author Matěj Týč is thrown out the window by this change. > > That's true, and an unfortunate limitation of git. We can potentially fit > two authors in by specifying one as with --author and the other as the > committer, but even then the gitlog-to-changelog script in gnulib doesn't > try to put that back into the generated ChangeLog file. :(
I don't think that's usable, the committer has generally nothing to do with authorship. A new tag is needed. >> There are many more patches with more that one author in the ChangeLog, >> and I don't think any of them has any mention of co-authors in their >> git commit message. > > I think the best way to handle that is to revert the ChangeLog file for > 2011 (which is very small anyway, and almost at an end too), and then to > find a way to put co-authors in the body of the gitlog message of future > commits so that gitlog-to-changelog can reconstitute a multi-author > commit. WDYT? Yes. I'm not worried about future commits. I'm worried (well, to be honest, *I* am not worried at all) about the past and fixing up that when the 2011 ChangeLog is to be set in stone will take care of that. The only way I can see that it will work generally for old commits is that gitlog-to-changelog notices that the file ChangeLog has been changed and digs out the co-authors from there. But that seems a bit fragile and also like a lot of work for a fairly minor problem. Or how minor is it? I don't have any stakes in that info, but FSF do... (BTW, "many more patches" was a bit of an overstatement, there are a dozen or so and Ralf or some other major contributer is mostly the single co-author. 72266fce was the first co-authored commit I stumbled upon, but it is hardly representative.) > I'm still on a huge kick to reduce the maintenance overhead involved in > looking after libtool, so I'm loathe to throw the baby out with the bathwater > by refusing to use gitlog-to-changelog altogether... I'll look into whether > there's some way to add 'Signed-off-by:' style Co-author meta-data to a git > commit, and patching upstream gitlog-to-changelog to take it into account. Yes, it looks like good progress from my cursory glances... > Cc:ing the smart folks at bug-gnulib in case some one has encountered and > solved this problem already... Cheers, Peter