Re: git history tracking across renames (and emacs support) (Was: The name gnus-cloud.el)

[Eli Zaretskii]

> From: Paul Eggert <address@hidden>
> Date: Tue, 2 Jan 2018 00:06:11 -0800
> Cc: address@hidden
> 
> What would be most helpful (and I realize I'm asking for a lot) would be 
> ChangeLog entries or commit messages (it doesn't matter which) that explain 
> the 
> *motivation* for each change.

IME, using log messages for this is OK, but it should be the last
resort, because log messages don't lend themselves to detailed
explanations, so the result will more often than not cryptic and not
detailed enough.  I would suggest the following alternatives:

  . the first priority should be to leave the explanation as comments
    in the code, if that is feasible, because then the commit explains
    itself, and the information is also available during simple code
    reading unrelated to VCS history searching;
  . if the change was discussed in some public forum, include the
    pointer to that discussion in the log message (bug number is a
    special case of this, but it's not the only one) -- this is
    preferable because many times these discussions include test cases
    that are important if you want to make sure further changes don't
    break what was fixed;
  . if none of the above is possible/practical, then yes, write the
    explanation in the log message, if the code change is not
    self-explanatory enough.

> In contrast, often it is counterproductive to 
> burden commit messages with mechanical details such as naming each and every 
> function that was modified, as it wastes developers' time to wade through 
> these 
> details when they're trying to look for stuff that's more important.

If you are looking for a specific change in a specific function, then
ChangeLog style is exactly what you want.  If you are looking for
something else, why would you look at the log messages at all, instead
of using VCS commands related to history and forensics?