Hmm. I'm getting this message annoyingly often, simply because a few files that used to be tracked are now generated, and so they exist in my tree but are no longer tracked. However, they may be tracked in an older tree that I pull, because in that older tree they _do_ exist, and we get the fatal: Untracked working tree file 'so-and-so' would be overwritten by merge. which is actually incorrect, because the merge result will not even _contain_ that untracked file any more. So the message is misleading - we should only consider this a fatal thing if we actually do generate that file as part of a git-read-tree, but if a merge won't touch a file, it shouldn't be "overwritten". It's true that if the _other_ end actually removed a file that we used to have (ie the file _disappears_ as part of the merge), then we should verify that that file matched what we're going to remove, but if the old index didn't contain the file at all, and the new index won't contain it either, it really should be a no-op. IOW, I think there is one "verify_absent()" too many somewhere, where we check this unnecessarily. I think it's the one in "deleted_entry()" in unpack-trees.c, but I'm not sure. Linus - 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