[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Darshit Shah
Subject: Re: [Bug-wget] [Bug-Wget] Policy on commit messages
Date: Sat, 1 Nov 2014 19:38:48 +0530
User-agent: Mutt/1.5.23 (2014-03-12)

On 11/01, 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 problem with ChangeLogs is that they only specify the changes as a fact. Not the actual logic / reasons behind them which is what we'd like to track in good commit messages.

I am not going to make detailed ChangeLog entries AND detailed commit

Sure, I personally find it too tedious to write both a ChangeLog and a commit message.

If we move to detailed commit messages (I would appreciate it), then we should
autogenerate ChangeLog files from the commit messages. You will find many
projects out there already doing so.

I am all for autogenerating the ChangeLogs.

If we can agree upon a frame or method, I would also appreciate a 'reason
field' for the changes. If it is not redundant. E.g. a commit message like
'fixing double free()' stands for itself.

Precisely what I'm looking for!


--- end quoted text ---

Thanking You,
Darshit Shah

Attachment: pgpfE64LMV_Z9.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]