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

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

[Greg KH]

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

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

[Junio C Hamano]

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.

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

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

[Junio C Hamano]

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

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

[Greg KH]

On Mon, Mar 17, 2008 at 05:16:41PM -0700, Junio C Hamano wrote:
> 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.

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

> 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

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

[Junio C Hamano]

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.