Re: Files not deleted when merging after a rename
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 ===
