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

From: Ingo Molnar <mingo@elte.hu>
Date: Oct 16, 2008, 07:20 UTC
Message-ID: <20081016072010.GA19188@elte.hu>
In-Reply-To: <7vy70ppiq1.fsf_-_@gitster.siamese.dyndns.org>

* Junio C Hamano <gitster@pobox.com> wrote:

Show 5 quoted lines

> 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