Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Basil L. Contovounesios]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> 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.

FWIW, one great benefit of this list for me is that I can quickly
'git log --grep' for all commits that mention a particular definition.
Doing the same with 'git log -G' is painfully slower and with a far
lower signal:noise ratio.

> Instead it should be an overview of what is done, why, and how.

That, or at the very least linking to the relevant bug/thread
discussions, is always a good thing to do and encouraged.

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

No, in such cases there are shortcuts you can take, such as "all callers
changed".

> I mean, sure it's a fun fact to know, but you'll have to review diff
> anyway. If anything, it only burdens you by forcing to check that each 
> function
> is on the list. Commit message should reveal the intention of the changes (and
> perhaps, if OP thinks changes may raise questions, they should also write the
> reasoning). And then a reviewer gotta check (in particular) this intention
> matches the actual code.

I doubt anyone disagrees with that.

-- 
Basil