Re: git reset --hard not removing some files

Martin Waitz [off-list ref] writes:

hoi :)

On Fri, Jun 02, 2006 at 07:57:57AM -0700, Junio C Hamano wrote:

quoted

I would agree in the reproduction recipe Martin gave there is no
problem but feature, but at the same time I suspect the recent
"reset --hard simplification" has introduced a true regression.

This may have been the bug that bit me.
Thanks for finding it although I was not able to reproduce it myself!

I found this somewhat the hard way myself.  I have:

        [pull]
                twohead = resolve

in my .git/config -- IOW, I usually do not use recursive
strategy myself.  When a merge with resolve strategy fails (and
with recent trend to busyboxify git commands, many merges
between my topics and "next" and/or "master" do), I relied on
"reset --hard" followed by the same merge of the topic using
"pull -s recursive" to recover things, but it didn't.  When
pulling a branch with builtin-*.c names into another branch with
older names, regressed "reset --hard" left builtin-*.c files
behind, and then the next merge attempt complained by saying my
untracked working tree files would be overwritten X-<.