Re: The fixes-bug field

[Paul Eggert <eggert@cs.ucla.edu>]

Eli Zaretskii wrote:
> If this information will be in the commit message (one suggestion so
> far, AFAIU), we should define its precise format and location within
> the commit message.

Let's define the format that we're already using in ChangeLog entries.
That is, a commit message that contains the string "Bug#16372" is
related to Bug#16372.  This would be simpler and more natural than
what we're doing now.

For example, with bzr, this ChangeLog entry:

	2014-01-07  Paul Eggert  <eggert@cs.ucla.edu>

		Fix misdisplay of interlaced GIFs with libgif5 (Bug#16372).
		* image.c (gif_load): libgif5 deinterlaces for us, so don't do
		it again.

corresponds to this commit message in trunk bzr 115915:

	Fix misdisplay of interlaced GIFs with libgif5.

	* image.c (gif_load): libgif5 deinterlaces for us, so don't do
	it again.

and means that the change is related to Bug#16372.

With git, I'd prefer using a commit message that matches what's in
the ChangeLog entry, as that's simpler anyway.   I.e., I'd rather use
this commit message:

	Fix misdisplay of interlaced GIFs with libgif5 (Bug#16372).

	* image.c (gif_load): libgif5 deinterlaces for us, so don't do
	it again.

This way, I could use vanilla vc-dwim to check in my changes,
rather the current song and dance where the commit message doesn't
quite match the ChangeLog entry (as the Bug# is missing)
and I run bzr with the --fixes option to communicate the Bug#.