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

[Eli Zaretskii <eliz@gnu.org>]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Tue, 10 Jul 2018 20:54:33 +0000
> 
> >> Is there any chance of evolving the commit message formatting
> >> requirements to lower the friction of making a commit and reduce
> >> redundancy?
> 
> EZ> IMO, what you'd like to have will actually _raise_ the friction
> EZ> (i.e. will be harder to provide) for many contributors, according to
> EZ> my experience of reviewing quite a few patches.
> 
> I really don't think the current format is easy for anyone, especially
> new developers.

The format is produced mechanically by Emacs commands, so I don't see
why suddenly the format is the issue.  Maybe I interpret "format" not
the way you meant it?

> It's also essentially repeating the headers from the diff.

It summarizes diffs, in a way, yes (and allows to add explanations if
appropriate).  I don't see that as a disadvantage: you don't always
have the ability to generate diffs (e.g., in a release tarball).

> Anecdotally, every time I want to make a larger commit with a lot of
> items, it feels to me like paperwork for its own sake and takes up a
> long time.

It usually takes me a few seconds per change, so I don't see why you
feel like that.

> Here's one way to write it more concisely and make it more readable,

I'm not sure we should try to be as concise as possible in this case.
Why does the number of characters matter?  With the current format,
most of those characters are automatically generated by Emacs.

> keeping in mind that the diff is part of the same log and is thus going
> to be right below the explanation

Not when a ChangeLog is generated from it and put in the tarball.

> commit 2fde6275b69fd113e78243790bf112bbdd2fe2bf
> Author: Basil L. Contovounesios <contovob@tcd.ie>
> Date:   Mon Jul 9 18:46:33 2018 -0700
> 
>     Adds and documents the new predicate function proper-list-p
> 
>     Factors out several one-off implementations of the same functionality.
>     For discussion, see emacs-devel thread starting at
>     https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00460.html.
> 
>     Implementation suggested by Paul Eggert <eggert@cs.ucla.edu> in
>     https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00138.html.

Here are the problems with this method:

 . How do you explain in CONTRIBUTE what should and what shouldn't be
   in a log message?  We have trouble getting contributors to follow
   the current format; this one will leave us no levers to ask them to
   do it correctly, I think.  The same situation exists with comments,
   but comments we can fix by followup commits, whereas log messages
   are carved in stone once pushed.

 . We lose information about the "several one-off implementations"
   where the changes were done.  You assume this information can
   easily be gleaned by examining the diffs, but even if the diffs are
   readily available, that assumption is not really true IME: it
   sometimes takes a non-trivial effort.  For example, determining the
   function or variable in which the change was made is not always
   easy, as the diff hunks don't always announce the right symbol,
   especially if a single hunk describes changes in several of them,
   or if the language of the source is not supported by Diff for these
   purposes.

 . With changes that touch a single function or a small number of
   them, your proposal will actually yield _longer_ logs, which goes
   against your intent.  Worse, it will require contributors to sit
   down and think how to describe a simple change without repeating
   the diffs, something that at least some of them will find not so
   easy, being non-native English speakers.