threads / discuss / 12712

renaming a file into a directory causes a pull error on older repos

Subject: renaming a file into a directory causes a pull error on older repos

## tl;dr

5 messages between Mar 16, 2008 and Mar 19, 2008.

replies: 4people: 2as markdown or json

Greg KH· Mar 16, 2008, 04:31 UTC · lore

So I had heard from someone else that this was a problem with git, but brushed it off as something that no one "normal" would ever run into. Well, I did tonight.

The problem:
  If you turn a file in a repository into a directory, and place files
  in that dir and commit it, any other person who had that repo cloned
  somewhere else will get an error when they try to pull and update
  their version.

The error for me is:
	fatal: Entry 'stats/results-18-22.txt' would be overwritten by merge. Cannot merge.
	Merge with strategy recursive failed.

I had turned the file "stats" into a directory.

So, any thoughts as to how to solve this for real? It's trivial to just blow away this repo and clone it again, which will solve the issue for now, but it seems like this might be good to get fixed...

thanks,

greg k-h

Junio C Hamano· Mar 18, 2008, 00:16 UTC · re: Greg KH · lore

Re: renaming a file into a directory causes a pull error on older repos

Greg KH <greg@kroah.com> writes:

Show 11 quoted lines

> The problem:
>   If you turn a file in a repository into a directory, and place files
>   in that dir and commit it, any other person who had that repo cloned
>   somewhere else will get an error when they try to pull and update
>   their version.
>
> The error for me is:
> 	fatal: Entry 'stats/results-18-22.txt' would be overwritten by merge. Cannot merge.
> 	Merge with strategy recursive failed.
>
> I had turned the file "stats" into a directory.

So...

 - originally "stats" was a file.

 - then one branch removes it and creates stats/results-18-22.txt file.

 - another branch keeps working elsewhere in the tree but has not touched
   the "stats" file.

Now, the above error message complains about stats/results-18-22.txt being overwritten, so I presume that:

 - You have checked out the branch that has stats/results-18.22.txt;

 - You are merging the other branch that still had stats as a file into
   that checked out branch with stats/results-18.22.txt file.

Are these presumptions correct?

Now, merge-recursive may be riddled with bugs in directory-file conflict detection area. The way it detects conflicts is quite bogus --- it builds a list of files and directories in ancestor, our side and the other side, and anything that changes directoryness is marked as conflict, when the right thing to do is to complain only if the checking out of the result needs to have a file and a directory at the same place.

But I do not think the above error message is from merge-recursive proper. "Entry X would be overwritten by merge. Cannot merge." is an error message the 3-way read-tree (driven from merge-recursive) issues when you have local changes to file X that will go away as the result of the merge, to prevent us from losing your local changes to the file. Didn't you have changes to that file when you did the merge?

I have spotted an unrelated bug in git-merge-one-file.sh that would have caused something similar symptom when you had used "resolve" strategy, by the way (unfortunately I do not think it applies to merge-recursive).

Junio C Hamano· Mar 18, 2008, 00:48 UTC · re: Junio C Hamano · lore

[PATCH] git-merge-one-file: fix longstanding stupid thinko

When a merge result creates a new file, and when our side already has a file in the path, taking the merge result may clobber the untracked file. However, the logic to detect this situation was totally the wrong way. We should complain when the file exists, not when the file does not exist.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * This is quite an old bug introduced by ed93b44 (merge: loosen
   overcautious "working file will be lost" check., 2006-10-08).  I
   originally wanted to catch the breakage Greg mentioned, but no such
   luck.

 git-merge-one-file.sh       |    5 ++-
 t/t1004-read-tree-m-u-wf.sh |   46 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 9ee3f80..e1eb963 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -48,10 +48,11 @@ case "${1:-.}${2:-.}${3:-.}" in
 	;;
 "..$3")
 	echo "Adding $4"
-	test -f "$4" || {
+	if test -f "$4"
+	then
 		echo "ERROR: untracked $4 is overwritten by the merge."
 		exit 1
-	}
+	fi
 	git update-index --add --cacheinfo "$7" "$3" "$4" &&
 		exec git checkout-index -u -f -- "$4"
 	;;
diff --git a/t/t1004-read-tree-m-u-wf.sh b/t/t1004-read-tree-m-u-wf.sh
index 9d1371c..283e77c 100755
--- a/t/t1004-read-tree-m-u-wf.sh
+++ b/t/t1004-read-tree-m-u-wf.sh
@@ -157,4 +157,50 @@ test_expect_success '3-way not overwriting local changes (their side)' '
 
 '
 
+test_expect_success 'D/F setup' '
+
+	git reset --hard &&
+
+	git checkout side-a &&
+	rm -f subdir/file2 &&
+	mkdir subdir/file2 &&
+	echo qfwfq >subdir/file2/another &&
+	git add subdir/file2/another &&
+	test_tick &&
+	git commit -m "side-a changes file2 to directory"
+
+'
+
+test_expect_success 'D/F' '
+
+	git checkout side-b &&
+	git read-tree -m -u branch-point side-b side-a &&
+	git ls-files -u >actual &&
+	(
+		a=$(git rev-parse branch-point:subdir/file2)
+		b=$(git rev-parse side-a:subdir/file2/another)
+		echo "100644 $a 1	subdir/file2"
+		echo "100644 $a 2	subdir/file2"
+		echo "100644 $b 3	subdir/file2/another"
+	) >expect &&
+	test_cmp actual expect
+
+'
+
+test_expect_success 'D/F resolve' '
+
+	git reset --hard &&
+	git checkout side-b &&
+	git merge-resolve branch-point -- side-b side-a
+
+'
+
+test_expect_success 'D/F recursive' '
+
+	git reset --hard &&
+	git checkout side-b &&
+	git merge-recursive branch-point -- side-b side-a
+
+'
+
 test_done

-- 
1.5.5.rc0.122.g8e28f

Greg KH· Mar 19, 2008, 01:51 UTC · re: Junio C Hamano · lore

Re: renaming a file into a directory causes a pull error on older repos

On Mon, Mar 17, 2008 at 05:16:41PM -0700, Junio C Hamano wrote:

Show 17 quoted lines

> Greg KH <greg@kroah.com> writes:
> 
> > The problem:
> >   If you turn a file in a repository into a directory, and place files
> >   in that dir and commit it, any other person who had that repo cloned
> >   somewhere else will get an error when they try to pull and update
> >   their version.
> >
> > The error for me is:
> > 	fatal: Entry 'stats/results-18-22.txt' would be overwritten by merge. Cannot merge.
> > 	Merge with strategy recursive failed.
> >
> > I had turned the file "stats" into a directory.
> 
> So...
> 
>  - originally "stats" was a file.

Yes.

>  - then one branch removes it and creates stats/results-18-22.txt file.

As well as many more files were aded to this directory.

>  - another branch keeps working elsewhere in the tree but has not touched
>    the "stats" file.

Correct, except the other branch did not add any new commits to the repo.

Show 9 quoted lines

> Now, the above error message complains about stats/results-18-22.txt being
> overwritten, so I presume that:
> 
>  - You have checked out the branch that has stats/results-18.22.txt;
> 
>  - You are merging the other branch that still had stats as a file into
>    that checked out branch with stats/results-18.22.txt file.
> 
> Are these presumptions correct?

Kind of, there are no "branches" in these repos, only the main one.

Show 13 quoted lines

> Now, merge-recursive may be riddled with bugs in directory-file conflict
> detection area.  The way it detects conflicts is quite bogus --- it builds
> a list of files and directories in ancestor, our side and the other side,
> and anything that changes directoryness is marked as conflict, when the
> right thing to do is to complain only if the checking out of the result
> needs to have a file and a directory at the same place.
> 
> But I do not think the above error message is from merge-recursive proper.
> "Entry X would be overwritten by merge. Cannot merge." is an error message
> the 3-way read-tree (driven from merge-recursive) issues when you have
> local changes to file X that will go away as the result of the merge, to
> prevent us from losing your local changes to the file.  Didn't you have
> changes to that file when you did the merge?

I don't think I did. I saved the repo on my disk at home, and when I get access to it tomorrow, I'll verify this.

I've tried to create a simple script to duplicate this problem, and I really can not do it at all, including trying to modify the file that got clobered by the directory name. Odd. I need to look at that repo and verify what I did to make sure it wasn't my fault here...

thanks for responding,

greg k-h

Junio C Hamano· Mar 19, 2008, 06:31 UTC · re: Greg KH · lore

Re: renaming a file into a directory causes a pull error on older repos

Greg KH <greg@kroah.com> writes:

> I've tried to create a simple script to duplicate this problem, and I
> really can not do it at all, including trying to modify the file that
> got clobered by the directory name.  Odd.  I need to look at that repo
> and verify what I did to make sure it wasn't my fault here...

You might have noticed that I've tried it as well.

And it is never your fault. If git prevented you from trashing your local modifications, that is a good thing that it errored out.