Re: git merge --abort

[John Tapsell <johnflux@gmail.com>]

2009/2/19 Junio C Hamano <gitster@pobox.com>:
> John Tapsell <johnflux@gmail.com> writes:
>
>>   It's not obvious how to abort a merge between two trees.  Would
>> aliasing  "git merge --abort"  to "git reset --hard"  be sensible?
>
> Not at all.  Especially when you have local changes.

Just to confirm that I've understood this - there's currently no way
at the moment to 'cancel' an abort.  In the example you gave:

>    $ edit goodbye.c ;# without "git add"
>    $ git merge other
>    Conflict in hello.c
>    $ git add goodbye.c
>    $ git merge --abort ;# ???

There's no reliable way of getting back to the state before the merge?


> The user's "git add goodbye.c" will make the state of the index unusable
> for the above outlined algorithm to tell what was changed by the merge and
> what were already different before the merge.
>
> So in general, even "merge --abort" implemented according to the above
> outline cannot be sold as "a safe procedure to recover to where you were
> before you started the last failed merge".  There is no such thing, unless
> you really educate the user not to expect miracle.
>
> If you mistakenly run "git merge" while your index is already unmerged
> (iow, after a failed merge before you resolved it nor resetted the index),
> the command aborts without touching the index nor the work tree.  If you
> implement "merge --abort" as outlined above, it will try to abort the
> previous conflicted merge, not this round which did not do anything, but
> again, the user could have done any other random things in addition to the
> attempt to run the second "git merge".
>
> Having said all that, I suspect
>
>        $ git reset --merge HEAD
>
> may do the right thing, if your git already has the option ;-)
>
>
> [Footnote]
>
> *1* CVS/SVN want to linearize so even if your local changes want to go
> directy on top of what you checked out, "cvs update" tries to replay your
> uncommitted changes on top of what comes as the latest from the central
> server, which could result in conflicts.  With git, you do not have to
> risk losing your local changes that way.  Instead, you can commit your
> local changes and then "git pull" will try to merge.  The merge can
> conflict and leave the same mess as "cvs update" would leave when it tries
> to replay your uncommitted changes, but a _huge_ difference here is that
> you get only one chance to resolve that conflict with CVS/SVN (because
> nothing records your local changes before the "update") and if you screw
> that up, you are out of luck.  With git, you have the local commit that
> records the changes you did on top of the old tip of the branch, and you
> can redo the merge.
>
> *2* I say *ought to*, and I am reasonably sure resolve strategy works
> correctly, but I wouldn't be surprised if recursive strategy which is the
> default these days still have corner case bugs when the merge involves
> renames and/or D/F conflicts).
>