Junio C Hamano wrote:
In any case, the reason why for full two years this switching between branches that have "foo/" and "foo" never surfaced as an issue is that people are saner than doing that in practice (and I think people coming from CVS couldn't do that before so they may not even think about doing so).
I can at least give you some insight into the real-world scenario that led to the current discussion. It's only slightly insane. :) We had a shell script called "foo" in our source directory. It had to turn into a multi-source-file app for various reasons. So the standalone script got replaced with a directory "foo" containing the source files.
I suppose one could argue that we should have called the original "foo.sh" or something and renamed it to "foo" at build/deploy time, but given that extensions aren't required on shell scripts (and that we have zillions of other scripts happily living without extensions) I suppose that just felt unnecessary.
By the way, Subversion required that we do this in two separate commits, the first to delete the shell script and the second to make the directory with the files in it. We originally tried to do both in one commit and it got confused. Then, some time after we'd done the separate commits in svn, we updated our git-svn repositories and ran into the problem.
In fact, when we tried to merge in the batch of changes from the git-svn tracking branch, we also ran into merge problems. Git got rather confused and the merge started complaining about files being untracked when in fact they were tracked in both branches! It looked like the index and/or working copy were left in an inconsistent state when the merge engine bailed out on the file-to-directory transition.
On my to-do list for next week is to try to come up with a minimally complex test case to demonstrate the problem, as the actual repositories in question are pretty convoluted and there were a bunch of other unrelated changes. I didn't mention it before now because I knew my description was certain to be too vague to be useful without a test case to look at.
We ended up successfully doing the merge by doing exactly what we had to do on the Subversion side: first explicitly merge up to the "delete the file" revision, then merge the "create the directory" revision. After that git was able to successfully fast-forward us through the subsequent revisions.
-Steve - 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