Martin Waitz <tali@xxxxxxxxxxxxxx> writes:
> 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-<.
-
: 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