{"thread":{"id":"12712","subject":"renaming a file into a directory causes a pull error on older repos","startedAt":"2008-03-16T04:31:38Z","lastAt":"2008-03-19T06:31:53Z","messageCount":5,"participants":["Greg KH","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72207","messageId":"20080316043138.GA7942@kroah.com","threadId":"12712","inReplyTo":null,"subject":"renaming a file into a directory causes a pull error on older repos","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2008-03-16T04:31:38Z","receivedAt":"2008-03-16T04:31:38Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"So I had heard from someone else that this was a problem with git, but\nbrushed it off as something that no one \"normal\" would ever run into.\nWell, I did tonight.\n\nThe problem:\n If you turn a file in a repository into a directory, and place files\n in that dir and commit it, any other person who had that repo cloned\n somewhere else will get an error when they try to pull and update\n their version.\n\nThe error for me is:\n\tfatal: Entry 'stats/results-18-22.txt' would be overwritten by merge. Cannot merge.\n\tMerge with strategy recursive failed.\n\nI had turned the file \"stats\" into a directory.\n\nSo, any thoughts as to how to solve this for real? It's trivial to just\nblow away this repo and clone it again, which will solve the issue for\nnow, but it seems like this might be good to get fixed...\n\nthanks,\n\ngreg k-h\n"},{"id":"72326","messageId":"7vlk4ganti.fsf@gitster.siamese.dyndns.org","threadId":"12712","inReplyTo":"20080316043138.GA7942@kroah.com","subject":"Re: renaming a file into a directory causes a pull error on older repos","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-18T00:16:41Z","receivedAt":"2008-03-18T00:16:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg KH writes:\n\n> The problem:\n> If you turn a file in a repository into a directory, and place files\n> in that dir and commit it, any other person who had that repo cloned\n> somewhere else will get an error when they try to pull and update\n> their version.\n>\n> The error for me is:\n> \tfatal: Entry 'stats/results-18-22.txt' would be overwritten by merge. Cannot merge.\n> \tMerge with strategy recursive failed.\n>\n> I had turned the file \"stats\" into a directory.\n\nSo...\n\n - originally \"stats\" was a file.\n\n - then one branch removes it and creates stats/results-18-22.txt file.\n\n - another branch keeps working elsewhere in the tree but has not touched\n the \"stats\" file.\n\nNow, the above error message complains about stats/results-18-22.txt being\noverwritten, so I presume that:\n\n - You have checked out the branch that has stats/results-18.22.txt;\n\n - You are merging the other branch that still had stats as a file into\n that checked out branch with stats/results-18.22.txt file.\n\nAre these presumptions correct?\n\nNow, merge-recursive may be riddled with bugs in directory-file conflict\ndetection area. The way it detects conflicts is quite bogus --- it builds\na list of files and directories in ancestor, our side and the other side,\nand anything that changes directoryness is marked as conflict, when the\nright thing to do is to complain only if the checking out of the result\nneeds to have a file and a directory at the same place.\n\nBut I do not think the above error message is from merge-recursive proper.\n\"Entry X would be overwritten by merge. Cannot merge.\" is an error message\nthe 3-way read-tree (driven from merge-recursive) issues when you have\nlocal changes to file X that will go away as the result of the merge, to\nprevent us from losing your local changes to the file. Didn't you have\nchanges to that file when you did the merge?\n\nI have spotted an unrelated bug in git-merge-one-file.sh that would have\ncaused something similar symptom when you had used \"resolve\" strategy, by\nthe way (unfortunately I do not think it applies to merge-recursive).\n"},{"id":"72330","messageId":"7vbq5camcb.fsf_-_@gitster.siamese.dyndns.org","threadId":"12712","inReplyTo":"7vlk4ganti.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] git-merge-one-file: fix longstanding stupid thinko","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-18T00:48:36Z","receivedAt":"2008-03-18T00:48:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When a merge result creates a new file, and when our side already has a\nfile in the path, taking the merge result may clobber the untracked file.\nHowever, the logic to detect this situation was totally the wrong way. We\nshould complain when the file exists, not when the file does not exist.\n\nSigned-off-by: Junio C Hamano \n---\n\n * This is quite an old bug introduced by ed93b44 (merge: loosen\n overcautious \"working file will be lost\" check., 2006-10-08). I\n originally wanted to catch the breakage Greg mentioned, but no such\n luck.\n\n git-merge-one-file.sh | 5 ++-\n t/t1004-read-tree-m-u-wf.sh | 46 +++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 49 insertions(+), 2 deletions(-)\n\ndiff --git a/git-merge-one-file.sh b/git-merge-one-file.sh\nindex 9ee3f80..e1eb963 100755\n--- a/git-merge-one-file.sh\n+++ b/git-merge-one-file.sh\n@@ -48,10 +48,11 @@ case \"${1:-.}${2:-.}${3:-.}\" in\n \t;;\n \"..$3\")\n \techo \"Adding $4\"\n-\ttest -f \"$4\" || {\n+\tif test -f \"$4\"\n+\tthen\n \t\techo \"ERROR: untracked $4 is overwritten by the merge.\"\n \t\texit 1\n-\t}\n+\tfi\n \tgit update-index --add --cacheinfo \"$7\" \"$3\" \"$4\" &&\n \t\texec git checkout-index -u -f -- \"$4\"\n \t;;\ndiff --git a/t/t1004-read-tree-m-u-wf.sh b/t/t1004-read-tree-m-u-wf.sh\nindex 9d1371c..283e77c 100755\n--- a/t/t1004-read-tree-m-u-wf.sh\n+++ b/t/t1004-read-tree-m-u-wf.sh\n@@ -157,4 +157,50 @@ test_expect_success '3-way not overwriting local changes (their side)' '\n \n '\n \n+test_expect_success 'D/F setup' '\n+\n+\tgit reset --hard &&\n+\n+\tgit checkout side-a &&\n+\trm -f subdir/file2 &&\n+\tmkdir subdir/file2 &&\n+\techo qfwfq >subdir/file2/another &&\n+\tgit add subdir/file2/another &&\n+\ttest_tick &&\n+\tgit commit -m \"side-a changes file2 to directory\"\n+\n+'\n+\n+test_expect_success 'D/F' '\n+\n+\tgit checkout side-b &&\n+\tgit read-tree -m -u branch-point side-b side-a &&\n+\tgit ls-files -u >actual &&\n+\t(\n+\t\ta=$(git rev-parse branch-point:subdir/file2)\n+\t\tb=$(git rev-parse side-a:subdir/file2/another)\n+\t\techo \"100644 $a 1\tsubdir/file2\"\n+\t\techo \"100644 $a 2\tsubdir/file2\"\n+\t\techo \"100644 $b 3\tsubdir/file2/another\"\n+\t) >expect &&\n+\ttest_cmp actual expect\n+\n+'\n+\n+test_expect_success 'D/F resolve' '\n+\n+\tgit reset --hard &&\n+\tgit checkout side-b &&\n+\tgit merge-resolve branch-point -- side-b side-a\n+\n+'\n+\n+test_expect_success 'D/F recursive' '\n+\n+\tgit reset --hard &&\n+\tgit checkout side-b &&\n+\tgit merge-recursive branch-point -- side-b side-a\n+\n+'\n+\n test_done\n-- \n1.5.5.rc0.122.g8e28f\n"},{"id":"72423","messageId":"20080319015156.GA8874@kroah.com","threadId":"12712","inReplyTo":"7vlk4ganti.fsf@gitster.siamese.dyndns.org","subject":"Re: renaming a file into a directory causes a pull error on older repos","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2008-03-19T01:51:56Z","receivedAt":"2008-03-19T01:51:56Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Mon, Mar 17, 2008 at 05:16:41PM -0700, Junio C Hamano wrote:\n> Greg KH writes:\n> \n> > The problem:\n> > If you turn a file in a repository into a directory, and place files\n> > in that dir and commit it, any other person who had that repo cloned\n> > somewhere else will get an error when they try to pull and update\n> > their version.\n> >\n> > The error for me is:\n> > \tfatal: Entry 'stats/results-18-22.txt' would be overwritten by merge. Cannot merge.\n> > \tMerge with strategy recursive failed.\n> >\n> > I had turned the file \"stats\" into a directory.\n> \n> So...\n> \n> - originally \"stats\" was a file.\n\nYes.\n\n> - then one branch removes it and creates stats/results-18-22.txt file.\n\nAs well as many more files were aded to this directory.\n\n> - another branch keeps working elsewhere in the tree but has not touched\n> the \"stats\" file.\n\nCorrect, except the other branch did not add any new commits to the\nrepo.\n\n> Now, the above error message complains about stats/results-18-22.txt being\n> overwritten, so I presume that:\n> \n> - You have checked out the branch that has stats/results-18.22.txt;\n> \n> - You are merging the other branch that still had stats as a file into\n> that checked out branch with stats/results-18.22.txt file.\n> \n> Are these presumptions correct?\n\nKind of, there are no \"branches\" in these repos, only the main one.\n\n> Now, merge-recursive may be riddled with bugs in directory-file conflict\n> detection area. The way it detects conflicts is quite bogus --- it builds\n> a list of files and directories in ancestor, our side and the other side,\n> and anything that changes directoryness is marked as conflict, when the\n> right thing to do is to complain only if the checking out of the result\n> needs to have a file and a directory at the same place.\n> \n> But I do not think the above error message is from merge-recursive proper.\n> \"Entry X would be overwritten by merge. Cannot merge.\" is an error message\n> the 3-way read-tree (driven from merge-recursive) issues when you have\n> local changes to file X that will go away as the result of the merge, to\n> prevent us from losing your local changes to the file. Didn't you have\n> changes to that file when you did the merge?\n\nI don't think I did. I saved the repo on my disk at home, and when I\nget access to it tomorrow, I'll verify this.\n\nI've tried to create a simple script to duplicate this problem, and I\nreally can not do it at all, including trying to modify the file that\ngot clobered by the directory name. Odd. I need to look at that repo\nand verify what I did to make sure it wasn't my fault here...\n\nthanks for responding,\n\ngreg k-h\n"},{"id":"72368","messageId":"7vlk4f442u.fsf@gitster.siamese.dyndns.org","threadId":"12712","inReplyTo":"20080319015156.GA8874@kroah.com","subject":"Re: renaming a file into a directory causes a pull error on older repos","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-19T06:31:53Z","receivedAt":"2008-03-19T06:31:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg KH writes:\n\n> I've tried to create a simple script to duplicate this problem, and I\n> really can not do it at all, including trying to modify the file that\n> got clobered by the directory name. Odd. I need to look at that repo\n> and verify what I did to make sure it wasn't my fault here...\n\nYou might have noticed that I've tried it as well.\n\nAnd it is never your fault. If git prevented you from trashing your local\nmodifications, that is a good thing that it errored out.\n"}]}