[PATCH, v3] wwwdocs: e-mail subject lines for contributions

[Richard Earnshaw (lists)]

On 03/02/2020 17:31, Michael Matz wrote:
> Hello,
> 
> On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> 
>> Where does your '50 chars' limit come from?  It's not in the glibc text,
>> and it's not in the linux kernel text either.  AFAICT this is your
>> invention and you seem to be the only person proposing it.
> 
> Nope, it's fairly common, so much so that it's included in the "commonly
> accepted rules" that googling for "git subject lines" gives you (as a
> snippet glimpse from some website), and that vim changes color when
> spilling over 50 chars.  I actually thought it was universal and obvious
> until this thread (which is why I admittedly only did the above google
> right before writing this mail).  For the rationale: 'git log --oneline'
> with hash and author or date should fit the usual 72 char limit.  (An
> 11-character hash plus space alone would come out as 60 chars for the
> subject)
> 
> That's also the reason why some people (certainly me) are nervous about or
> dislike all the "tags" in the subject line.  E.g. what essential
> information (and subjects are for essential info, right?) is "[committed]"
> (or, even worse "[patch]") supposed to transport?  If the rest of the
> subject doesn't interest me, I don't care if something was committed or
> not; if it _does_ interest me, then I'm going to look at the mail/patch
> either way, if committed or not; at which point the info if the author
> required review or has already committed it could be gives in the body as
> well.  Similar for some other metainfo tags.  (The "subsystem:" is good,
> though).
> 
> And if we must have these tags, then why not at least short ones?  Why
> isn't "[cmt]" or something enough?  There will be very few tags, so they
> become mnemonic pretty much immediately.  What becomes clearer when
> writing "[patch v2 1/13]" in comparison to "[v2 1/13]"?
> 

The idea is that the [...] part is NOT part of the commit, only part of 
the email.  'git am' would strip leading [...] automatically unless 
you've configured, or asked git to do otherwise.  So that leading part 
is not counted for the length calculation.

R.

> 
> Ciao,
> Michael.
>