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

[Radon Rosborough <radon.neon@gmail.com>]

> But if you have suggestions for clarifying CONTRIBUTE, please tell.

I think that CONTRIBUTE needs to give a step-by-step guide for how to
generate a commit message with Magit, since Magit is certainly either
the most popular or second most popular version-control frontend for
Emacs.

It should probably also provide a step-by-step guide for doing this
with VC. As soon as I am linked to documentation about editing
ChangeLog files, I will assume I've gone astray, unless it's explained
why editing ChangeLog files is necessary in order to generate a commit
message.

> I guess it depends on the projects. I contribute to several other
> projects, like GDB, Gawk, and Texinfo

Well, those are all GNU projects. So I think that's the difference. It
seems to me that ChangeLog is a "GNU thing". As are mailing lists,
avoidance of GitLab, using debbugs, etc.

> Like I said: free text log messages leave a lot of space for
> disagreement about what is and what isn't a good message.

This is true, but it seems to me that we already have this problem.
After all, the current format doesn't say anything about how to
actually describe your change. It just tells you how to replicate the
diff in your commit message. By dropping the format, we would only be
losing the replicated diff information; we wouldn't be losing any
directions on how to communicate useful information that *can't* be
auto-generated, because there are no such instructions now.

> IME, new contributors want clear and concise instructions; telling
> them to read a long blog will definitely turn off many of them.

I think the blog does a much better job of getting across its
information clearly, concisely, and understandably:

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

Plus, everybody knows this already, since virtually every open-source
project follows more or less these guidelines for commit messages.
I've seen many projects which link to exactly the same blog article,
in fact! On the contrary, it seems to me like the only people who know
about ChangeLog format are regular contributors to GNU projects.

> Think about it: why would I support radical changes in our
> procedures that get in the way of my work, when I have so little
> time to work on Emacs and so much to do?

Of course. And I don't mean to criticize your work at all; if I came
across that way, it is my fault and I apologize.

I only wish to push for an agreement that "if somebody were willing to
do the work to remove the ChangeLog format, then the patch would be
accepted". Otherwise, who is going to write a patch?