On Wed, 15 Oct 2008, Junio C Hamano wrote:
quoted text
>
> When aborting a failed merge that has brought in a new path using "git
> reset --hard" or "git read-tree --reset -u", we used to first forget about
> the new path (via read_cache_unmerged) and then matched the working tree
> to what is recorded in the index, thus ending up leaving the new path in
> the work tree.

Looks good to me. And from my tests, I think "git checkout -f" didn't have 
this problem at all, because it ends up using not got read-tree, but doing 
its own "reset_tree()" that uses unpack_trees().

I do wonder if "git reset" should perhaps be written in those terms, 
instead of just being a wrapper around git read-tree. But the patch looks 
fine.

		Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html