Re: [RFC] Commit message format

[Jonas Hahnfeld]

Am Freitag, den 07.02.2020, 12:37 -0500 schrieb Dan Eble:
> On Feb 7, 2020, at 10:39, Han-Wen Nienhuys <
> address@hidden
> > wrote:
> > There are a couple of downsides to this format:
> > * The number takes up space in the
> >    git log --format=short
> 
> upside: the number appears in git log —format=short
> 
> > * The number is meaningless without the site that hosts the tracker
> 
> exaggerated, but I see your point
> 
> >    Link to code review
> >    Link to issue
> > 
> > By embedding the links, we offer something clickable to whomever is
> > browsing the commit message.
> 
> -1, maybe.  Will the commit messages be rewritten when we migrate to a 
> different issue tracker or the provider decides to reorganize the URL paths?

No, please don't: It will change all commit ids, making up many dead
references.

> A stale link from which I must extract an ID would annoy me more than a bare 
> ID, I expect.
> 
> (I might have put links in a commit message or two, but please do as I say, 
> not as I do.)
> 
> Also, I've worked with issue trackers that scan commit messages for IDs in a 
> specific format (e.g. "#1234" or "[1234]") and turn them into hyperlinks from 
> the ticket to the related commits in a repository view.  It's probably best 
> to postpone dictating a citation format until we know the constraints of the 
> tools we move to (hoping we do).  We might even be able to configure patterns 
> for recognizing our older citations.

+1

From Han-Wen:
> Somewhat relatedly, I would like to propose to use SHA1s + subject
> lines to refer to previous changes, rather than issue numbers, eg.
> 
>    04a0dc ("Disable Python's hash randomization")
> 
> this makes the reference impervious to problems with the issue tracker
> (network outage, renumbering due to server migrations, etc). Including
> the subject line makes it easier to intuitively understand what is going on.

+1, and I might have already started doing so in some places. If the
commit title is too long (see above), I think it's safe to drop the
"Issue XXXX" prefix.
For SHA1, I'd recommend using more than 6 chars to avoid collisions.
The Linux kernel encourages 12 characters [1], but I think we are good
with less. $ git log --oneline currently shows 10 chars for the
LilyPond repo, that should be a safe bet.

Jonas


1: 
https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst#2-describe-your-changes

signature.asc
Description: This is a digitally signed message part