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

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

 



Ingo Molnar <mingo@xxxxxxx> writes:

> Does your fix mean that all i have to do in the future is a hard reset 
> back to HEAD, and that dangling files are not supposed to stay around?

As long as the index *somehow* knows about these new files, they are
removed.

The situation is:

 (0) you start from a HEAD that does not have path xyzzy;
 (1) you attempt to merge a rev that has path xyzzy;
 (2) the merge conflicts, leaving higher staged index entries for the
     path.
 (3) you decide not to conclude the merge by saying "reset --hard".

The old logic for "reset" was to remove paths that exist in the index at
stage #0 (i.e. cleanly merged) and not in HEAD.  The patch changes the
rule to remove paths that exist in the index at any stage (i.e. including
the ones that have conflicted and not resolved yet) and not in HEAD.


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