On 03/02/2020 17:48, Michael Matz wrote:
Hi,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
The idea is that the [...] part is NOT part of the commit, only part of
the email.
I understand that, but the subject line of this thread says "e-mail
subject lines", so I thought we were talking about, well, exactly that;
and I see no value of these tags in e-mails either.
(They might have a low but non-zero value for projects that use
a single mailing list for patches and generic discussion, but we are not
such project)
Basically: if they are deemed to clutter the git log for whatever reason,
then there must be a very good argument for why they not also clutter
e-mail subject lines, but instead are essential to have there,
but not in the log.
Well, I'd review a patch differently depending on whether or not it was
already committed, a patch requiring review or an RFC looking for more
general comments, so I *do* think such an email prefix is useful.
'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.
There's still e-mail netiquette which also should be obeyed, or at least
not contradicted by git netiquette.
The 50 char limit seems to come from wanting git log --oneline to not
wrap in an 80 column terminal. Whilst laudable, I'm not sure that such
a limit doesn't become too restrictive and then lead to
hard-to-understand summaries.
R.
