Re: git reset --hard not removing some files

From: Junio C Hamano <junkio@cox.net>
Date: Jun 4, 2006, 09:31 UTC
Message-ID: <7vfyilclna.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060604091601.GN14325@admingilde.org>

Martin Waitz <tali@admingilde.org> writes:

Show 9 quoted lines

> hoi :)
>
> On Fri, Jun 02, 2006 at 07:57:57AM -0700, Junio C Hamano wrote:
>> 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-<.