* Junio C Hamano <gitster@xxxxxxxxx> 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
--
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
