From: Mark Desnoyer <hidden> Date: 2016-06-15 22:44:07
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
From: Alex Riesen <hidden> Date: 2016-06-15 22:44:07
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?
From: Mark Desnoyer <hidden> Date: 2016-06-15 22:44:07
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 [off-list ref] wrote:
Mark Desnoyer, Mon, Jan 21, 2008 20:45:07 +0100:
quoted
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?
From: Mark Desnoyer <hidden> Date: 2016-06-15 22:44:07
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 [off-list ref] wrote:
Mark Desnoyer, Mon, Jan 21, 2008 22:45:40 +0100:
quoted
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?
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 ===
From: Alex Riesen <hidden> Date: 2016-06-15 22:44:08
Dmitry Potapov, Wed, Jan 23, 2008 09:19:42 +0100:
On Tue, Jan 22, 2008 at 08:28:25AM +0100, Alex Riesen wrote:
quoted
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.