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

* Junio C Hamano [off-list ref] 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.

i've met this problem in various variants in the past few months, and i 
always assumed that it's "as designed" - as Git's policy is to never 
lose information unless forced to do so. (which i find very nice in 
general, and which saved modification from getting lost a couple of 
times in the past)

the situations where i end up with a messed up working tree [using 
git-c427559 right now]:

 - doing a conflicted Octopus merge will leave the tree in some weird 
   half-merged state, with lots of untracked working tree files that not 
   even a hard reset will recover from. The routine thing i do to clean 
   up is:

      git reset --hard HEAD
      git checkout HEAD .
      git ls-files --others | xargs rm              # DANGEROUS

   doing git checkout -f alone is not enough, as there might be various 
   dangling files left around.

 - git auto-gc thinking that it needs to do another pass in the middle 
   of a random git operation, but i dont have 10 minutes to wait so i 
   decide to Ctrl-C it.

 - doing the wrong "git checkout" and then Ctlr-C-ing it can leave the
   working tree in limbo as well, needing fixups. If i'm stuck between
   two branches that rename/remove files it might need the full fixup
   sequence above.

 - if a testbox has a corrupted system clock, its git repo and the 
   kernel build can get confused. This is to be expected i think - but
   the full sequence above will recover the corrupted tree. Not much Git
   can do about this i guess.

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?

	Ingo