Re: git history tracking across renames (and emacs support)

[Eli Zaretskii <eliz@gnu.org>]

> Cc: tzz@lifelogs.com, larsi@gnus.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 13 Jul 2018 09:15:55 -0500
> 
> On 07/13/2018 03:14 AM, Eli Zaretskii wrote:
> > I find the summary line to be a nuisance in too many cases.
> 
> Although the summary line is sometimes a nuisance to write, when done
> well it is so useful that it's clearly a net win over our old way of
> doing things. Many Git user interfaces list only the summary lines, and
> for good reason: they let you quickly scan a list of commits looking for
> what happened in those commits. Writing a useful summary line is thus a
> real service to later developers, and is far more helpful than the file,
> function and variable names that the GNU coding standards currently
> require in ChangeLogs.
> 
> The primary UI that we promote on the web
> <http://git.savannah.gnu.org/cgit/emacs.git> lists just summary lines. I
> just now looked at the most recent ten summary lines in Emacs master,
> and eight of them seemed useful. The two I found less useful were
> "Unbreak bootstrap" (a motivation for the change, but not enough
> description) and "Fix Bug#32107" (likewise). It'd be helpful for us to
> encourage people to write commit messages with summary lines that are
> suitable for later readers.

All true.  Like I said: this is the price we pay for using Git and
related UIs instead of ChangeLog, where header lines were optional, to
be used where that really made sense (which was relatively rare).
With Git, they're mandatory, because if we don't use them, various
dependent features will not work well, or not at all.

Like almost every other feature, this one has its price.