Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 16, 2008, 06:27 UTC
- Message-ID
- <7vprm1jbq5.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <alpine.LFD.2.00.0810151615550.3288@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 15 quoted lines
> On Wed, 15 Oct 2008, Junio C Hamano wrote: >> >> 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.
Let's do this for 'maint' and I'll let others think about possible improvements, then ;-).