Re: Commit header lines (was: git history tracking across renames (and emacs support))

[Paul Eggert]

On 07/14/2018 01:58 AM, Eli Zaretskii wrote:
> There are header lines that don't
> add any information to the log message, in many cases they are just
> the first entry slightly rephrased.

If a summary line is a shorter version of the main text, that's a good
thing. It's like a good title for a news article or a research paper: it
restates the main text briefly, and there is real value in that.

If a summary line is merely a copy of the first sentence of the log,
then of course you're right: why bother? Just say it once, in the
summary. Again, this is like an article or paper.

> In other cases, they say
> something uninformative like "Minor copyedits SOMEWHERE".

If the copyedits truly are minor those are OK. The main point of
one-line summaries is to let readers quickly see which changes are
relevant to their concerns. For example the most recent commit using
that form, "Minor copyedits in Emacs manual in macos.texi", is OK;
unless I'm interested in editing macos.texi I can quickly skip over that
commit.

If the copyedits aren't truly minor then of course that would be a
problem, as would be any incorrect summary line.

> And in
> many/most of those cases I see no better way to phrase the header line
> that would fit into 65 characters.

If it's "Minor copyedits in Emacs manual in macos.texi" then we're doing
OK already; I wouldn't worry about rephrasing that one, anyway.

By the way, the usual suggested length limit for summary lines is 50
characters, not 65.