[Top][All Lists]

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

Re: Why are so many great packages not trying to get included in GNU Ema

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

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

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.

reply via email to

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