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

[Stefan Monnier]

> 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).

FWIW, while I don't see the need to have such info when diffs aren't
available, I do sometimes appreciate the summarizing part: it's
easier to scan the commit message to see "oh there were 3 ad-hoc
definitions of proper-list-p replaced by the new one" than to try and
extract that info from the diff.

Whether this occasional benefit is worth the effort, I don't know.

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

It also takes me very little time, but our view is strongly biased here,
since we're doing it so often that we got really good at it.  For people
who don't contribute often to Emacs (or other projects using a similar
format) I'm sure it takes them significantly more time.

>  . 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.

Agreed.


        Stefan