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

[Eli Zaretskii]

> From: Radon Rosborough <address@hidden>
> Date: Wed, 11 Jul 2018 11:08:54 -0600
> Cc: Ted Zlatanov <address@hidden>, address@hidden, emacs-devel 
> <address@hidden>
> 
> Wait, what? I was writing these commit messages manually, and it was a
> huge pain. How do you do it automatically?

Semi-automatically.  See my other message where I hope I explained
what I meant.

> I looked in CONTRIBUTE and there was lots of information about the
> format, but none about how to auto-generate it. The section
> "Generating ChangeLog entries" linked me to the "Change Log Commands"
> section of the manual, which is all about ChangeLog files and doesn't
> mention commit messages at all.

I hope you will understand the connection after reading my other
message.  But if you have suggestions for clarifying CONTRIBUTE,
please tell.

> CONTRIBUTE also mentioned something
> about `vc-dwim' but this is not relevant since I use Magit.

I believe magit has a command that helps you produce the log message.

> No other project I contribute to has this kind of requirement, and
> it most definitely raises the bar to new contributors.

I guess it depends on the projects.  I contribute to several other
projects, like GDB, Gawk, and Texinfo, and they all maintain ChangeLog
files, let alone require the format.  GNU Make doesn't keep ChangeLog
files, but its log messages are formatted like ChangeLog.

So I guess my experience is 100% opposite of yours.

> I don't understand the above comment at all; maybe you can
> elaborate?

I think I already did, in my other messages.

> If you're concerned about new contributors not knowing how to write
> commit messages in the absence of the existing format, why not just
> link them to <https://chris.beams.io/posts/git-commit/>?

Like I said: free text log messages leave a lot of space for
disagreement about what is and what isn't a good message.  IME, new
contributors want clear and concise instructions; telling them to read
a long blog will definitely turn off many of them.

> I think that when discussing all sorts of these issues on emacs-devel
> (using modern code hosting, modern issue tracking, modern CI, modern
> pull request workflow, ...) the discussion is biased because most of
> the people who would benefit from moving into the future simply don't
> bother to contribute to Emacs or post here. It's an opportunity cost
> that you will not be able to measure by posting an inquiry to a
> mailing list(!). And naturally the maintainers all have extensive
> experience with using the existing tooling and are inclined to think
> it is easier to use than it actually is.

There's no way around that: the only practical way of changing the
Emacs development practices is from within.  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?
Any project is shaped by those who work on it the most.