[m-rev.] for post-commit review: fix mantis bug #367

Peter Wang novalazy at gmail.com
Sat Dec 6 12:34:49 AEDT 2014


On Fri, 05 Dec 2014 17:43:38 +1100 (EST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Fri, 5 Dec 2014 16:11:09 +1100, Peter Wang <novalazy at gmail.com> wrote:
> 
> > On Wed, 03 Dec 2014 18:20:15 +1100 (EST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > > Fix Mantis bug #367.
> > 
> > Please avoid using only a bug number for commit summary.
> 
> It is the git limit on the commit description. It is hard enough to describe
> the change itself in 50 characters; including the bug number makes it
> almost impossible. So I usually pick one or the other, not both.
> The meat of the diff explains the diff anyway, and is not squeezed.

You can go (much) longer; even the Linux kernel specifies 75 chars.
If you have to choose, I suggest that the descriptive summary is more
useful when browsing the history (gitk, git log --oneline, github, etc.)
A bug number number in the main body text will still by found when
searching, e.g. with git log --grep.

> Or are you worried about the compiler moving Mid < Hi to AFTER
> the lookup? I am pretty sure the compiler is not allowed to do that,

Yes, that is the worry.  The "strict commutative" operational semantics
allows it, does it not?

Peter



More information about the reviews mailing list