bug#9847: [PATCH 3/3] maint: use gnulib's gitlog-to-changelog instead of a ChangeLog file.

[Peter Rosin]

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