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

[Eli Zaretskii]

> From: Ted Zlatanov <address@hidden>
> Cc: Marcin Borkowski <address@hidden>,  Stefan Monnier <address@hidden>,  
> address@hidden,  address@hidden
> Date: Wed, 11 Jul 2018 13:54:49 +0000
> 
> Emacs does not produce the format mechanically, unless you know the
> right commands. It's IMHO a pain to learn them.

There's only one command: "C-x 4 a".

> EZ> It summarizes diffs, in a way, yes (and allows to add explanations if
> EZ> appropriate).  I don't see that as a disadvantage: you don't always
> EZ> have the ability to generate diffs (e.g., in a release tarball).
> 
> Releases communicate through NEWS and release notes.
> 
> If the users need to read the commit logs to find what files and
> functions have changed since the last release, something's wrong with
> the release process.

We have no release notes except NEWS.  And NEWS only mentions new
features and changes in behavior, it doesn't mention bugfixes, which
is a large portion (if not the majority) of changes in any release.

ChangeLog files provide information about changes when one has no
up-to-date repository around.

> As Stefan said, it's mainly because I don't do it as often as you.
> Familiarity takes time to achieve and sustain. In this case, it feels
> like I'm doing work to satisfy the computer rather than to improve Emacs.

This old curmudgeon found solution to such situations: where I do
something rarely enough to be unable to trust my memory, I keep notes.
It's a surprisingly effective and efficient way, you should try that
some time.

> I'm advocating readability and less mechanical content, not conciseness
> for its own sake.

I understand.  I'm just saying that it takes more time and effort to
generate such less mechanical content, so you are probably raising the
bar, not lowering it.

> Log messages don't have to be carved in stone. You're justifying a human
> cost with a technical side effect of the version control system.

It doesn't have to be so, but AFAIK the last VCS where log messages
could be amended was CVS.  In our brave new world, log messages _are_
carved in stone once committed.  That's the reality in which we live,
whether we like it or not.

> I agree it's hard to explain what should be in a log message, but that's
> because there's no perfect solution to the problem of writing down the
> thought process and decisions that led to a solution. Certainly, I don't
> think the current mechanical content improves that situation. It
> *formalizes* the description of a specific subset of the decisions.

It gives me easy tools to teach newcomers how to write log messages we
want to see.  Once this is taken from me, what can I say to a
contributor who claims that his/her log message is just fine, because
there's nothing in CONTRIBUTE to say it isn't?

> Maybe there's a format that can link better and with less effort between
> code and commit description in these complex cases.

If someone would like to write a command that looks at the last commit
(or several commits), and generates a skeleton of a log entry, I'm all
for it.  (People will have to "git commit --amend" to use such a
command, but that's not a problem, I think, and could also be
automated.)