Re: [PATCH] t: avoid alternation (not POSIX) in grep's BRE

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

 



On Thu, May 28, 2020 at 12:20:49PM -0700, Junio C Hamano wrote:

> I've seen "Fixes: bug number" in projects that maintain bug
> databases and automatically updates the status of the named bug when
> a commit with such a footer hits certain integration branches; the
> utility of such a usecase would be fairly obvious.
> 
> But "Fixes: <commit>" makes me nervous.  One reason is because a
> commit very often introduces multiple bugs (or no bugs at all), so
> which one (or more) of the bug is corrected cannot be read from such
> a footer that _only_ blames a particular commit.
> 
> 	Side note: also "fixes:" footer would cast a claim made when
> 	a commit was created in stone---which may later turn out to
> 	be false.  But the issue is not unique to "Fixes: <commit>";
> 	"Fixes: <bugid>" suffers exactly from the same problem.
> 
> An interesting aspect of "Fixes: <commit>" is that we can use it to
> easily see who is the buggiest by dividing number of buggy commit by
> number of total commits per author ;-)

Thanks for writing this out. I agree with all of it.

You could probably get interesting numbers in our project by grepping
for [0-9a-f]{7,} in commit messages to see which commits are referenced
a lot. Those aren't always bug-fixes exactly, but they are often "we did
this in commit XYZ, but that missed this case". Or maybe it would just
tell you which commits are interesting enough that we keep coming back
to them. ;)

> I'd rather not to see people adding random footers whose utility is
> dubious, but for this particular one, I am not against it strongly
> enough to be tempted to declare an immediate ban.

Sounds reasonable.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux