[Top][All Lists]

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

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-messag

From: Dmitry Gutov
Subject: Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,
Date: Sun, 05 Apr 2015 22:47:05 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

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

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.

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.

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

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.

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

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

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.

reply via email to

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