emacs-devel
[Top][All Lists]
Advanced

[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: Mon, 06 Apr 2015 15:03:23 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

On 04/06/2015 10:54 AM, Eli Zaretskii wrote:

Then please tell what you had in mind, perhaps it would be good to
have that added.

I use 'git rebase -i' for that. Not sure if we actually want to mention rebasing in the instructions.

But if not, should they recommend reviewing each commit right away after it's made?

In my book it's an understandable position of a busy person who wants
a simple job of making an upstream change to "just work".  Such people
_will_ learn with good help, but much slower.

Well, here's hoping. IME, Git is better learned from fundamentals, but hopefully these careful instructions will make it easier for people to ignore the former, without major consequences.

I think you fail to understand how humiliating that would be.  That's
okay, let's talk in, say, 30 years, and see where you stand then ;-)

I'd call that delegating, and I'm sure many people would be okay with it. But of course, if there's a similar motivated individual 30 years from now to write a new guide, that would be great too.

When someone is in grave trouble, what do you expect?  He can be
taught fishing after he's out of trouble, but not before.  You don't
start teaching people how to avoid a fire before putting the fire out.

Being hungry is the best motivation to learn fishing. And as we know now, his situation was fairly normal: a history containing two normal local commits and lagging behind the remote master otherwise.

So what was needed is a pull, a merge resolving the conflicts, and then a push. The situation was complicated by the need to resolve ChangeLog conflicts manually (or else there may have been no conflicts at all), which is something that was a problem for me as well after Emacs's transition to Git. While I know how to merge, it wasn't obvious how exactly those kind of conflicts should be resolved, which ordering to use, dates, etc. And it's annoying to have to do it each time manually.



reply via email to

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