> About the "lost remove", I think it is related to the fact that > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
