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

[Konstantin Kharlamov]

On Thu, 2020-06-18 at 19:49 +0200, Ricardo Wurmus wrote:
> 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.

While it may be useful, but explicit examples may be more interesting. Right now
when I read your text about this list in the context of resolving rebase
conflicts, I only see the downside that if the conflict came up because a
function was renamed, you need to go fix the commit message too.

Even worse: if upon rebasing a function was renamed, you may not get any
conflicts (i.e. because thunk you modified didn't include the beginning of the
function), and now your commit message is broken without you even noticing.

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

It is possible, it's just that I do not see this. Convincing someone that the
commit message with the list provides more benefit than without it requires
examples that make it explicit. 

So far the whole thread (both this part and the one with Dmitry) had only
negative examples, i.e. why having the list is a burden to anyone.

Let me sum up the positive mentions: so far, you just say it simplifies review
for you, but I don't know your workflow, there may be many factors that make you
assert that, which does not necessarily applies to everyone. Dmitry said the
list makes better commit messages from novices, but again when I tried to dig
deeper, that discussion died.

You see, presence of negative examples and lack of positive ones doesn't make
that look too convincing.