emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Radon Rosborough
Subject: Re: git history tracking across renames (and emacs support)
Date: Wed, 11 Jul 2018 11:08:54 -0600

> The format is produced mechanically by Emacs commands, so I don't
> see why suddenly the format is the issue. Maybe I interpret "format"
> not the way you meant it?

Wait, what? I was writing these commit messages manually, and it was a
huge pain. How do you do it automatically?

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. CONTRIBUTE also mentioned something
about `vc-dwim' but this is not relevant since I use Magit. Also, the
information is completely impossible to find via Google because it is
a tiny niche thing that nobody else uses.

> IMO, what you'd like to have will actually _raise_ the friction
> (i.e. will be harder to provide) for many contributors, according to
> my experience of reviewing quite a few patches.

FWIW, I'm totally on the side of "get rid of the format". No other
project I contribute to has this kind of requirement, and it most
definitely raises the bar to new contributors. I don't understand the
above comment at all; maybe you can elaborate?

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/>?

---

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.

Perhaps I am wrong about this; if so, please correct me. But I've
gotten a very strong impression in this direction in the course of
being subscribed to this list and maintaining several open-source
Emacs projects over the past year.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]