On Tue, Jan 22, 2008 at 08:28:25AM +0100, Alex Riesen wrote:
quoted text
> 
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html