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.
