# Files not deleted when merging after a rename 8 messages from 2008-01-21 to 2008-01-24. Participants: Mark Desnoyer, Alex Riesen, Dmitry Potapov. Thread: https://gitlist.dev/t/11696 ## Mark Desnoyer, 2008-01-21 19:45 Subject: Files not deleted when merging after a rename Message-ID: URL: https://gitlist.dev/e/d997e2110801211145o5fe0a1bbpb1e32dd71b70568e%40mail.gmail.com ``` 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 ``` ## Alex Riesen, 2008-01-21 21:20 Subject: Re: Files not deleted when merging after a rename Message-ID: <20080121212015.GB5263@steel.home> URL: https://gitlist.dev/e/20080121212015.GB5263%40steel.home In-Reply-To: ``` 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? ``` ## Mark Desnoyer, 2008-01-21 21:45 Subject: Re: Files not deleted when merging after a rename Message-ID: URL: https://gitlist.dev/e/d997e2110801211345x6ee35d48s2038fbd773149110%40mail.gmail.com In-Reply-To: <20080121212015.GB5263@steel.home> ``` 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 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? > > ``` ## Alex Riesen, 2008-01-22 07:28 Subject: Re: Files not deleted when merging after a rename Message-ID: <20080122072825.GA2971@steel.home> URL: https://gitlist.dev/e/20080122072825.GA2971%40steel.home In-Reply-To: ``` 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? ``` ## Mark Desnoyer, 2008-01-23 02:08 Subject: Re: Files not deleted when merging after a rename Message-ID: URL: https://gitlist.dev/e/d997e2110801221808r22f19ec9qc1c452e13c7698df%40mail.gmail.com In-Reply-To: <20080122072825.GA2971@steel.home> ``` 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 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? > > ``` ## Dmitry Potapov, 2008-01-23 08:19 Subject: Re: Files not deleted when merging after a rename Message-ID: <20080123081942.GM14871@dpotapov.dyndns.org> URL: https://gitlist.dev/e/20080123081942.GM14871%40dpotapov.dyndns.org In-Reply-To: <20080122072825.GA2971@steel.home> ``` 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 === ``` ## Alex Riesen, 2008-01-24 07:52 Subject: Re: Files not deleted when merging after a rename Message-ID: <20080124075202.GB3193@steel.home> URL: https://gitlist.dev/e/20080124075202.GB3193%40steel.home In-Reply-To: ``` 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. ``` ## Alex Riesen, 2008-01-24 07:56 Subject: Re: Files not deleted when merging after a rename Message-ID: <20080124075638.GC3193@steel.home> URL: https://gitlist.dev/e/20080124075638.GC3193%40steel.home In-Reply-To: <20080123081942.GM14871@dpotapov.dyndns.org> ``` 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 ```