Re: [PATCH 2/2] gitlog-to-changelog: support 'tiny change' commits.

[Gary V. Vaughan]

Hi Jim,

On 15 Nov 2011, at 20:10, Jim Meyering wrote:
> Gary V. Vaughan wrote:
>> On 15 Nov 2011, at 19:02, Jim Meyering wrote:
>>> Propose a patch to maintain.texi.
>> 
>> I don't want to get into a debate over the merits of generated
>> ChangeLogs with RMS, which I already know he doesn't like.
> 
> I don't recall any objection to generated ChangeLogs.
> No one ever gave me negative feedback about what I do in coreutils
> (since 2008), diffutils, grep, etc., and as such I wouldn't expect
> any debate.  It's established practice.

Nonetheless, I'd rather avoid the possibility.

And I certainly don't want to get sidetracked into writing a whole
new chapter for maintain.texi, which currently avoids discussing VCS
entirely.

>> So never mind this second patch, I'll just keep it in the
>> gl/build-aux/gitlog-to-changelog.diff of my projects.  Any other
>> project that likes it can find a copy there, or in the bug-gnulib
>> archives. (Although I still think that if you use gitlog-to-changelog
>> to generate all your ChangeLogs without tracking and correctly
>> generating the '(tiny change)' annotations somehow, then you're not
>> respecting the maintainer guidelines on ChangeLog entries.)
>> 
>> How about pushing the multi-author patch?
> 
> I will re-review/test it and reply tomorrow.

Excellent! Thanks :)

> I can give a little feedback already: I do not want to
> add a bourne-shell git commit-msg hook script to gnulib.
> If I thought the one we're using in coreutils were ready,
> I would have proposed to add something general based on it.

Agreed.  Writing a new perl script is well outside my expertise anyway.

Since git seems to allow but a single commit-msg hook script, a nice
goal would be to have some sort of framework for executing snippets
from separate files for various checks (maybe in .git/hooks/commit-msg.d).
That way projects could install the framework, and add a selection of
checks from gnulib (in Perl I imagine), and some bespoke checks in a
language the maintainer is comfortable with... much better than having
to cobble together a monolithic script from checks that would be convenient
assembled from various sources.

> There are two issues:
> - we need more experience with the idea and the framework.
>  I suspect that very few people have used it so far.
> - it is not ready for gnulib: I am rewriting it in Perl,
>  which is more portable, and with git, guaranteed to be available.

All sounds good to me.  Especially if you don't ask me to write any more
perl code! ;)

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)