emacs-devel
[Top][All Lists]
Advanced

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

Re: The fixes-bug field


From: Paul Eggert
Subject: Re: The fixes-bug field
Date: Thu, 16 Jan 2014 23:58:23 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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  <address@hidden>

                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#.



reply via email to

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