Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 05 Apr 2015 22:47:05 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rms@gnu.org, emacs-devel@gnu.org
> 
> On 04/05/2015 06:43 PM, Eli Zaretskii wrote:
> 
>  >> 1) Forget the "push automatically after commit" nonsense
> >
> > The discussion is waaaay beyond that, so this is no longer relevant.
> 
> That's not my impression from the last sentence in 
> http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg00156.html

Wrong impression.

> > not very relevant
> > to the issue at hand, which had to do with user confusion more than
> > with anything else.
> 
> Hence the item 2 below.

That item is a dead end in practice, and is too harsh even if it were
practical.

> > And if we think double-checking each commit before pushing is a must,
> > we should make VC support that seamlessly.  After all, all Richard
> > used was VC.
> 
> We can come up with a more automatic solution, but even now it's 
> entirely doable using VC: `C-x v L' to open the log buffer, and when in 
> it, `C-m' to read the commit message, `d' to see the corresponding diff.

You are missing the point: I meant "C-x v v", not some other command
available with VC.  It's "C-x v v" that got Richard in trouble in the
first place, by trying to commit a single file in the middle of a
failed merge.

> Editing the already-created commits is more complicated, but I think 
> there was some advice on that subject too, in the humongous thread.

It's also on the Wiki.

> >> 2) People who don't know how to do that, and are unwilling to learn, or
> >> who aren't confident in their results anyway should post patches to the
> >> mailing list.
> >
> > I disagree.  We should let people who want to use a CVS-like workflow
> > do that.  It's possible if done correctly.
> 
> I'm not saying it's not possible, but a wrong commit message is extra 
> work for someone else who will have to correct it. It'll become more so 
> when the change log files are auto-generated.

Which is why it is important to help those users find the right
procedures they can safely follow.

> > The previous instructions
> > for that were sub-optimal, but I think they are now much more clear,
> > accurate, and concise to allow using that workflow safely.
> 
> It's better, but I think recommending `git diff origin/master' as the 
> first option is suboptimal, because it ignores the commit messages, 
> which we do want to look right.

I don't mind switching the order.  I myself use "git show".  It's just
that most others suggested "git diff", and its syntax is a bit simpler
when more than one commit is involved.

> > I see no reasons for being this harsh just because some contributors
> > don't yet master Git enough to use it like we think they should.
> 
> The workflow details aside, I think a committer should be motivated 
> enough to examine the result of their work before pushing. And if they 
> don't know how, learn that on their own.

I don't think there's lack of motivation in this case.

> But not everyone has to be an Emacs committer. That's not harsh: people 
> can have better priorities in life.

Applied to veteran Emacs developers, it _is_ harsh, at least IMO.

> >> Had Richard started with that, a lot of time would've been saved, on
> >> many ends.
> >
> > Time spent helping someone is time well spent, at least as long as
> > it's my time.
> 
> Cue the "teach a man how to fish" proverb. It seems to me that the 
> result is only one fish on Richard's table, and one that was pretty 
> haphazardly prepared.

We all need help from time to time.  I see no reason to tell people
they goofed too many times, especially if they already know that.