2009/2/19 Junio C Hamano <gitster@xxxxxxxxx>: > John Tapsell <johnflux@xxxxxxxxx> 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). > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
