Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:

> 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 ;-).

--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux