Re: [Bug-wget] [Bug-Wget] Policy on commit messages

[Giuseppe Scrivano]

Mike Frysinger <address@hidden> writes:

> On 01 Nov 2014 14:05, Tim Rühsen wrote:
>> Am Samstag, 1. November 2014, 05:43:11 schrieb Darshit Shah:
>> > In the last few days we've seen a huge flurry of activity and a large 
>> > number
>> > of patches have been committed to the code base. As someone who was
>> > traveling and hence unable to keep up with the mailing lists, I tried to
>> > catch up by looking at the code base and the changes that have been made.
>> > 
>> > It would turn out that the commit messages aren't very informative on the
>> > last few commits. Unless I know the context of the change from the mailing
>> > list, it would be very difficult to understand why that particular change
>> > was important. Both the ChangeLog and commit messages usually only describe
>> > the change in literal terms but not in their logical reasoning.
>> > 
>> > I propose that henceforth, all commits be reviewed for detailed 
>> > descriptions
>> > of not only the syntactical changes, but also the logical reasons behind
>> > the change. This will help us in the long term to follow through the
>> > changes in the code base and also make it easier for new contributors to
>> > understand why some things are the way they are.
>> 
>> As I understood, for GNU projects we have very detailed ChangeLog entries 
>> and 
>> thus very short commit messages.
>
> the GNU project ChangeLogs are not useful in git.  their intention is to be 
> mechanical and describe what's changed so that in a CVS world, you could 
> easily 
> revert.  most GNU projects that have moved to git have also updated their 
> commit 
> message policy to not be useless (although they still hold onto ChangeLogs).  
> some have automated the procedure though so that they put the info into the 
> commit message and then the ChangeLog is generated from that.  see coreutils 
> git 
> messages as an example.
> -mike

changelogs are crap, not useful to anyone, that is my opinion.

We are required to have them because of the GNU Coding standards.  I was
already having a discussion privately with RMS in these last days trying
to change this requirement from the 80', but I had no luck so far.

In the meanwhile I had a look at gitlog-to-changelog that is included
into gnulib and we should probably move to it, it will save headaches
when we have to merge patches.  So my proposal is that for now we move
more high-level changelog-like messages in the commit message (i.e. no
need to document all the minor changes that is easier to get from the
code itself) and then generate the ChangeLog file from the current
ChangeLog that we we will keep around as read-only + all the commit
messages since we decide to move to this new model.

The first step is probably to merge all the current ChangeLogs in a
single one, in the root directory and then start from there.

Regards,
Giuseppe