Re: [PATCH] Documentation: warn against merging in a dirty tree

From: Avery Pennarun <apenwarr@gmail.com>
Date: Sep 18, 2008, 18:18 UTC
Message-ID: <32541b130809181118s1a4cffa6u3ad139aa05443ea6@mail.gmail.com>
In-Reply-To: <alpine.LFD.1.10.0809180804100.3337@nehalem.linux-foundation.org>

On Thu, Sep 18, 2008 at 11:15 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

Show 10 quoted lines

> On Mon, 15 Sep 2008, Avery Pennarun wrote:
>>
>> But how do you abort a *failed* merge in a situation like Linus's
>> example?  "git reset --hard HEAD" would destroy the unstaged Makefile
>> change.
>
> As mentioned by others, sometimes you are simply willing to take the risk.
> If I have dirty data, I still want to merge, because (a) my dirty data is
> a _convenience_ and (b) the risk of me having to do a "git reset" is
> pretty low anyway.

In that case, my next question is how you pull off (b), because that's *way* better than just being able to undo when I get myself into trouble :) I do and then reset test merges all the time.

Show 8 quoted lines

> That said, it's actually kind of sad that we don't expose a real
> capability that the git plumbing does have. Namely
>
>        git read-tree -u -m HEAD ORIG_HEAD
>
> should do the right thing if you want to undo a merge (except it doesn't
> actually write ORIG_HEAD to be the new head: you could use "git reset"
> with --soft to do that, or just git update-ref).

Hmm,

   $ git read-tree -u -m HEAD ORIG_HEAD
   fatal: you need to resolve your current index first

It appears that the above would be great for undoing a *non*conflicting merge, but that's not as important ;)

Show 13 quoted lines

> So it _may_ be that something like
>
>        [alias]
>                undo = !git read-tree -u -m HEAD ORIG_HEAD && git reset --soft ORIG_HEAD
>
> would actually give you "git undo".
>
> So we have the technology, and we just don't _expose_ that capability as a
> "git reset" thing. And we probably should. In fact, that is often the
> thing people really want, and it would have made sense to have it as the
> default action, but the initial design for "git reset" was literally as a
> way to get you out of a sticky corner when you had unmerged entries and
> you just wanted to throw away crud.

Note that if we were going to do an undo, it would be nice to be careful about allowing multiple consecutive undos. "git undo; git undo;" shouldn't be a no-op, it should undo two things. At least, that's how the rest of the world (okay, my text editor) works. "git redo" could be the opposite of "git undo".

I imagine some trick using the reflog would thus be better here than updating ORIG_HEAD.

Since that's a lot of work, I'd propose having a first pass at the undo operation use ORIG_HEAD and then just delete or rename ORIG_HEAD, so that 'git undo; git undo' is meaningless.

Have fun,

Avery