Re: Cygwin: problem with renaming and case

[Linus Torvalds <torvalds@linux-foundation.org>]

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