Re: ChangeLogs in commit messages

[Joel Brobecker <brobecker at adacore dot com>]

> I've put together a quick pre-receive hook (inlined below).  Each
> received commit on the "master" branch that touches the "gdb"
> subdirectory gets its message checked.  The check itself is fairly
> cursory: it splits the message using the "YYYY-MM-DD  NAME  <EMAIL>"
> headers, checks each is preceeded by a path starting with "gdb/" and
> ending with "/", and checks each is followed by more "NAME  <EMAIL>"
> lines, blank lines, or lines starting with tab.  I don't know how
> comprehensive we want to be here as the message should already have
> been checked over by the reviewer.
> 
> I've never done anything server-side with git before, so there may
> well be things I'm missing here.  I was mainly experimenting to see
> how difficult this all was :)

Just looking quickly at the script for the typical mistakes I made
when I first started dabbling into this kind of script:

  . The SHA1 is 000[...]0 when creating a new reference
    (Eg: creating a new branch). But that's an invalid SHA1

  . Same when deleting a reference. the "new rev" is 0.

  . I would suggest we do that on all branches except branches
    under a specific namespace (thinking "vendor" branches, TBD).

  . When creating a new branch, you really don't want to start
    checking the entire history again, so you need to find the
    branchpoint and use that as the "old rev".

I would like to push again for the format without the date and author
email but the simpler gdb/ChangeLog: instead.  The commit already
stores that information (author name and email, committer date),
whereas requiring the user to provide it in the rev log means that
the date needs to be maintained throughout the lifetime of the patch
until that patch gets pushed. Same thing when cherry-picking a patch
from master to a release branch.

-- 
Joel