Files not deleted when merging after a rename

Files not deleted when merging after a rename

[Mark Desnoyer]

Hi,

I've run across a small problem and I was wondering if I could get
some help. I have two users A and B. They are both git-cloned from a
common repository on a different server.

User A moves a directory:
foo/bar/ ==> bar
using:
git mv foo/bar bar
git commit
git push

Meanwhile, user B is doing some other changes that are completely
unrelated and has a few local commits. Now, when user B pulls from the
repository (git pull), and returns no errors merging, the directory
"bar" is created, but "foo/bar" is not deleted, although, it becomes
untracked.

Any ideas why the merge isn't deleting foo/bar? The users are using
git version 1.5.2.5 in Ubuntu Hoary. Thanks in advance.

-Mark

Re: Files not deleted when merging after a rename

[Alex Riesen]

Mark Desnoyer, Mon, Jan 21, 2008 20:45:07 +0100:
> Hi,
> 
> I've run across a small problem and I was wondering if I could get
> some help. I have two users A and B. They are both git-cloned from a
> common repository on a different server.
> 
> User A moves a directory:
> foo/bar/ ==> bar
> using:
> git mv foo/bar bar
> git commit
> git push
> 
> Meanwhile, user B is doing some other changes that are completely
> unrelated and has a few local commits. Now, when user B pulls from the
> repository (git pull), and returns no errors merging, the directory
> "bar" is created, but "foo/bar" is not deleted, although, it becomes
> untracked.

Directories are never tracked. It should have been deleted though.
Did it have (or still has) some untracked files in it?

Re: Files not deleted when merging after a rename

[Mark Desnoyer]

Alex,

The directory did not have any untracked files in it. Looking a little
more carefully, I realized that there were subdirectories in foo/bar/.
All the files in foo/bar and its subdirectories were deleted
correctly, but the actual directory structure still exists.

-Mark

On Jan 21, 2008 4:20 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> Mark Desnoyer, Mon, Jan 21, 2008 20:45:07 +0100:
>
> > Hi,
> >
> > I've run across a small problem and I was wondering if I could get
> > some help. I have two users A and B. They are both git-cloned from a
> > common repository on a different server.
> >
> > User A moves a directory:
> > foo/bar/ ==> bar
> > using:
> > git mv foo/bar bar
> > git commit
> > git push
> >
> > Meanwhile, user B is doing some other changes that are completely
> > unrelated and has a few local commits. Now, when user B pulls from the
> > repository (git pull), and returns no errors merging, the directory
> > "bar" is created, but "foo/bar" is not deleted, although, it becomes
> > untracked.
>
> Directories are never tracked. It should have been deleted though.
> Did it have (or still has) some untracked files in it?
>
>

Re: Files not deleted when merging after a rename

[Alex Riesen]

Mark Desnoyer, Mon, Jan 21, 2008 22:45:40 +0100:
> Alex,
> 
> The directory did not have any untracked files in it. Looking a little
> more carefully, I realized that there were subdirectories in foo/bar/.

Were these subdirectories containing exclusively tracked files?
Or is it Winblows and some process was blocking the deletion?

Re: Files not deleted when merging after a rename

[Mark Desnoyer]

Definitely not Winblows. I try to avoid it even with a 10ft pole. I'm
running Ubuntu 7.10.

Could you define "exclusively tracked files"? I'm not sure what you mean here.

-Mark

On Jan 22, 2008 2:28 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
> Mark Desnoyer, Mon, Jan 21, 2008 22:45:40 +0100:
> > Alex,
> >
> > The directory did not have any untracked files in it. Looking a little
> > more carefully, I realized that there were subdirectories in foo/bar/.
>
> Were these subdirectories containing exclusively tracked files?
> Or is it Winblows and some process was blocking the deletion?
>
>

Re: Files not deleted when merging after a rename

[Dmitry Potapov]

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 ===

Re: Files not deleted when merging after a rename

[Alex Riesen]

Mark Desnoyer, Wed, Jan 23, 2008 03:08:21 +0100:
> Definitely not Winblows. I try to avoid it even with a 10ft pole. I'm
> running Ubuntu 7.10.

Anything mounted in?

> Could you define "exclusively tracked files"? I'm not sure what you mean here.

I asked if the directories contained something else besides the files
known to git.

Re: Files not deleted when merging after a rename

[Alex Riesen]

Dmitry Potapov, Wed, Jan 23, 2008 09:19:42 +0100:
> 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.

Right. I extended Cc a bit, to remind of the problem

> 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.

Probably. It is all in merge-recursive.c