|
From: | Dmitry Gutov |
Subject: | Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers |
Date: | Sun, 14 Jun 2020 01:09:23 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
On 13.06.2020 22:23, Konstantin Kharlamov wrote:
FTR, I am all for having good commit messages. It is IMO a must have for any git project. But having a list of function names with description for each does not make one. Instead it should be an overview of what is done, why, and how.
Having a standard that increases the likelihood of having such a description in the commit message without having to ask the contributor twice is not a bad thing.
Suppose you have a patch that deduplicates the same code pattern across 34 functions by factoring it out to a single short function. Do you really need that list? I mean, sure it's a fun fact to know, but you'll have to review diff anyway.
Yes and no. If I get the purpose of the diff, I could scan the contents more superficially (depending on what kind of changes are proposed, and where).
If anything, it only burdens you by forcing to check that each function is on the list.
I usually don't.
Commit message should reveal the intention of the changes (and perhaps, if OP thinks changes may raise questions, they should also write the reasoning).
That, too.In any case, ChangeLog-style commit messages *are* a barrier for contributing, and one could argue that in the end they don't bring enough benefit to offset that.
But our experience shows that they do bring a certain benefit.
On that matter I often love to quote a post from 2009 by Peter Hutterer, a libinput and Linux HID subsystem maintainer. A post that is old but is not outdated http://who-t.blogspot.com/2009/12/on-commit-messages.html
It's a pretty good guideline. But one that's a bit harder to check and enforce.
[Prev in Thread] | Current Thread | [Next in Thread] |