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

[Ricardo Wurmus]

João Távora <joaotavora@gmail.com> writes:

> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
>
>> Oh, sure I can be mistaken. I see you replied to Dmitry's email, I had a 
>> follow-
>> up on it. Does my follow-up mail change your opinion, or perhaps do you have
>> some example in mind that a good commit message without the list would not
>> solve?
>
> I might have read it.  I'm not saying good commit messages are
> impossible without the summarizing list; I'm just saying it's a good
> thing to have, something I've grown accustomed to.  When composing them,
> they're a good exercise in self-review.  But of course there's more ways
> to skin a cat.  This just happens to be the way we use here.
>
> It's not "for fun".  Of course is a mental cost in composing them,
> especially if you don't do it often and use the friendly C-x 4 a
> shortcut.  But there is a gain, too.

I’d also like to note that this list can be invaluable when rebasing
commits and resolving conflicts.  It’s not strictly necessary (just like
other parts of a version control workflow are not strictly necessary),
but it can serve as a sanity check in a time when the diff is not
authoritative as it is in flux.

An explanation as to why things were done is also very useful in those
cases, but an overview on the *conceptual* changes at the procedure
level (rather than the plain diff that’s only concerned with lines and
not with the context in which the changes occurred) provides additional
valuable information that the commit diff itself cannot provide.

You can, of coures, browse the code with the diff applied and without
and see the full context in which those lines were changed, but even
with a nice interface like the one magit provides that’s much more work
than looking at the commit summary.

-- 
Ricardo