On Fri, 21 Mar 2008, Frank wrote: > > Don't know exactly if this is a bug or a feature or something in the middle, > but I have a lot of problems while changing just the casing of file names and > using git mv und cygwin. It's not exactly a bug, it's a "feature" of that crap we call Windows and OS X that makes them claim that soem files exist even though they don't. > Here's a test case: > [ ... ] > echo "NEW AAA" >Aaa.txt > git add Aaa.txt > git commit -m "Added Aaa" > #aaa.txt exists in master, Aaa.txt in new_branch > git checkout master > > Last command gives: "fatal: Untracked working tree file 'aaa.txt' would be > overwritten by merge". So what happens here is that git is trying to switch back to master, which has the file "aaa.txt" in it, and before it does that switch is wants to make sure that the new files it creates won't be overwriting some untracked file data that you may already have. Now, you don't *really* have a file called "aaa.txt" any more, but what git is doing is that it knows it will create that file, so before it starts writing it, it will do a "lstat()" on the file to see that there is nothing there. So git will lstat() that pathname "aaa.txt", and your absolute crap filesystem will say "sure, I have that file". Because it will match the "Aaa.txt" that you do have from before the merge. Now, you're tracking "Aaa.txt" in the branch you're leaving, and git knows that, but git also knows that the branch you're leaving is *not* tracking "aaa.txt", so obviously the copy of "aaa.txt" that the filesystem reports is not saved anywhere, and git says "I refuse to overwrite it, because that would destroy your untracked content". > I know I can use git checkout -f but the problem returns while others do > merging/pulling from my repo, etc. Case-insensitive filesystems are utter crap. Git doesn't really support them, but you can use git on them pretty well as long as you don't introduce these kinds of issues by hand. For now, -f is the only reasonable thing to do. Will we fix it? I suspect we will teach git about these kinds of name aliases some day, but most of the git developers avoid broken filesystems, and the ones that are on broken filesystems tend to avoid having the same name in different cases, so it's not exactly a high priority. It's actually nontrivial to get right and test (on sane filesystems). I could probably whip up something that gets US-ASCII right for this particular case (ie just switching between branches) reasonably easily (ie do a pretty stupid "works for the common case" thing without even trying to be anythign else). I just really haven't had a lot of motivation to do it. Let's see if I can get the energy.. Linus -- 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
