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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 18, 2008, 00:16 UTC
Message-ID: <7vlk4ganti.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080316043138.GA7942@kroah.com>

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