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

From: Jeff King <peff@peff.net>
Date: May 28, 2020, 20:35 UTC
Message-ID: <20200528203516.GA1245262@coredump.intra.peff.net>
In-Reply-To: <xmqqsgfj3lym.fsf@gitster.c.googlers.com>

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

Show 18 quoted lines

> 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