On Mon, Mar 17, 2008 at 05:16:41PM -0700, Junio C Hamano wrote: > Greg KH <greg@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
