> About the "lost remove", I think it is related to the fact that
quoted text
> we try to be usable in a sparsely checked out work tree, and
> during a two-way merge (aka "switching branches") we consider a
> missing file equivalent to an unmodified file and this might be
> a bug in the logic to implement it there.

It seems I can hit something like this
with sparesely checked out work tree, too:

On the linux tree from linus:

git clone -n -s <url> linux-2.6
cd linux-2.6
git update-ref HEAD v2.6.23-rc4
git checkout HEAD -- drivers/infiniband
ls Kbuild
	ls: Kbuild: No such file or directory
git merge v2.6.23-rc5
	Updating b07d68b..40ffbfa
	Checking 22271 files out...
	100% (22271/22271) done


	Fast forward
	error: Ref refs/heads/master is at e7afef45b41f5f5e2211322f083247e42ba13a78 but
	expected b07d68b5ca4d55a16fab223d63d5fb36f89ff42f
	fatal: HEAD: cannot lock the ref

ls Kbuild
	Kbuild
git log v2.6.23-rc4..v2.6.23-rc5 -- Kbuild

So
a ton of files not present earlier were checked out. But why?
merge failed with a fatal error. But why?

I think I found some way to screw the repo, but what did
I do wrong?


Here's another example:

git clone -n -s <url> linux-2.6
cd linux-2.6
git checkout v2.6.23-rc4
rm -fr `ls | grep -v drivers`
rm -fr `ls -d drivers/* | grep -v infiniband`
git merge v2.6.23-rc5
... lots of output ...
ls

	arch           drivers  include  kernel       Makefile  net
	Documentation  fs       init     MAINTAINERS  mm        security

given than Makefile and MAINTAINERS were removed,
why are they re-added now?

git --version
git version 1.5.3.1.1.g1e61

-- 
MST
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html