Re: [RFH] straightening out "read-tree -m"

[Steven Grimm <koreth@midwinter.com>]

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