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. 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). 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 NOTE NOTE! I did _not_ test that the git read-tree thing actually works, or that the above alias does the right thing. Caveat testor! You're on your own. But I agree that we should have something like that. Linus -- 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
