Re: git commit message conventions

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

On Mon, Jun 08, 2015 at 11:01:33AM -0500, Stan Shebs wrote:
> These days, ChangeLogs are not as useful as commit histories for
> things that changed last week or last month, but after a year or two,
> commit histories get convoluted, sometimes too messed up to interpret

I'm not sure what you mean by that.  The convention of having clear
and detailed descriptions of changes is very recent and is not even
properly followed in a lot of GNU projects I have tracked.  Do you
have any examples where commit histories got convoluted despite there
being strigent conventions in place to ensure that each change is
adequately described in the commit log?

> anymore; and after ten years, the ChangeLog is the only record that
> has survived multiple changes of version control system, and the
> accidental destruction of commit history that happened during one of
> the transitions. 1/2 :-)

Version control transitions don't happen every other year.  In fact,
they won't happen for anything more than once a decade and making a
workflow unbearable tedious just to maintain a file that may perhaps
be proven to be marginally useful once in a decade seems like
overkill.  The ChangeLog is definitely useful in cases where it is
included in exactly the same commit as its changes, since it is useful
in pointing out changes in a git-blame where there were only deletions
in the target files.  That case however is quite rare and again it
doesn't seem worthwhile to maintain a file for this in-tree at the
cost of foregoing the convenience of git-am'in patches and pushing
them intact and opening up the possibility of a number of related
automation.

I know, I did say I wasn't going to crib about the ChangeLog...

Siddhesh

Attachment: pgp9HR5rj2Qql.pgp
Description: PGP signature