On Tue, Jan 22, 2008 at 08:28:25AM +0100, Alex Riesen wrote: > > Were these subdirectories containing exclusively tracked files? > Or is it Winblows and some process was blocking the deletion? The issue is not Windows specific and the problem can be reproduced with different versions of Git including the latest from Git master. In fact, user B does not have to made any changes, it is enough that merge was not fast-forward. In contrast with fast-forward merge, which just update the references, the recursive merge requires the working directory to perform the merge. Because directories are not trucked, there is no way to tell at the end whether an empty directory was created by user before or it became empty as result of merge. Probably, the problem can be solved by remembering the list of empty directories before performing a real merge and then, on success, to remove all empty directories that are not in that list. Here is a script that demonstrates the issue. === CUT === #!/bin/sh set -e rm -rf shared userA userB mkdir shared cd shared git init mkdir -p foo/bar for line in Files not deleted when merging after a rename; do echo $line; done > foo/bar/testfile git add foo/bar/testfile git commit -m 'add foo/bar/testfile' cd .. git clone file://$PWD/shared/.git userA git clone file://$PWD/shared/.git userB cd userA git mv foo/bar bar git commit -m 'mv foo/bar bar' git push cd .. cd userB echo 'more' >> foo/bar/testfile git commit -a -m 'edit foo/bar/testfile' git pull find * === CUT === - 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
