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)
