{"thread":{"id":"12794","subject":"Cygwin: problem with renaming and case","startedAt":"2008-03-21T16:07:04Z","lastAt":"2008-03-22T20:18:10Z","messageCount":11,"participants":["Frank","Linus Torvalds","Avery Pennarun","Dmitry Potapov","streamlake@tiscali.it","Brian Dessent","Junio C Hamano","Steffen Prohaska","Nagy Balázs"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72601","messageId":"47E3DD28.4030302@tiscali.it","threadId":"12794","inReplyTo":null,"subject":"Cygwin: problem with renaming and case","fromName":"Frank","fromEmail":"streamlake@tiscali.it","sentAt":"2008-03-21T16:07:04Z","receivedAt":"2008-03-21T16:07:04Z","isPatch":false,"sender":{"key":"streamlake@tiscali.it","avatar":null},"body":"Hi,\nDon't know exactly if this is a bug or a feature or something in the \nmiddle, but I have a lot of problems while changing just the casing of \nfile names and using git mv und cygwin. Here's a test case:\n\nmkdir testrename\ncd testrename\ngit init\necho \"AAA\" >aaa.txt\necho \"BBB\" >bbb.txt\ngit add aaa.txt\ngit add bbb.txt\ngit commit -m \"First commit\"\ngit checkout -b new_branch\ngit mv aaa.txt ccc.txt\ngit commit -a -m \"Moved file\"\necho \"NEW AAA\" >Aaa.txt\ngit add Aaa.txt\ngit commit -m \"Added Aaa\"\n#aaa.txt exists in master, Aaa.txt in new_branch\ngit checkout master\n\nLast command gives: \"fatal: Untracked working tree file 'aaa.txt' would \nbe overwritten by merge\".\nI know I can use git checkout -f but the problem returns while others do \nmerging/pulling from my repo, etc.\nThanks,\nFrank\n"},{"id":"72605","messageId":"alpine.LFD.1.00.0803211037160.3020@woody.linux-foundation.org","threadId":"12794","inReplyTo":"47E3DD28.4030302@tiscali.it","subject":"Re: Cygwin: problem with renaming and case","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-03-21T17:46:55Z","receivedAt":"2008-03-21T17:46:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 21 Mar 2008, Frank wrote:\n>\n> Don't know exactly if this is a bug or a feature or something in the middle,\n> but I have a lot of problems while changing just the casing of file names and\n> using git mv und cygwin.\n\nIt's not exactly a bug, it's a \"feature\" of that crap we call Windows and \nOS X that makes them claim that soem files exist even though they don't.\n\n> Here's a test case:\n> [ ... ]\n> echo \"NEW AAA\" >Aaa.txt\n> git add Aaa.txt\n> git commit -m \"Added Aaa\"\n> #aaa.txt exists in master, Aaa.txt in new_branch\n> git checkout master\n> \n> Last command gives: \"fatal: Untracked working tree file 'aaa.txt' would be\n> overwritten by merge\".\n\nSo what happens here is that git is trying to switch back to master, which \nhas the file \"aaa.txt\" in it, and before it does that switch is wants to \nmake sure that the new files it creates won't be overwriting some \nuntracked file data that you may already have.\n\nNow, you don't *really* have a file called \"aaa.txt\" any more, but what \ngit is doing is that it knows it will create that file, so before it \nstarts writing it, it will do a \"lstat()\" on the file to see that there is \nnothing there.\n\nSo git will lstat() that pathname \"aaa.txt\", and your absolute crap \nfilesystem will say \"sure, I have that file\". Because it will match the \n\"Aaa.txt\" that you do have from before the merge.\n\nNow, you're tracking \"Aaa.txt\" in the branch you're leaving, and git knows \nthat, but git also knows that the branch you're leaving is *not* tracking \n\"aaa.txt\", so obviously the copy of \"aaa.txt\" that the filesystem reports \nis not saved anywhere, and git says \"I refuse to overwrite it, because \nthat would destroy your untracked content\".\n\n> I know I can use git checkout -f but the problem returns while others do\n> merging/pulling from my repo, etc.\n\nCase-insensitive filesystems are utter crap. Git doesn't really support \nthem, but you can use git on them pretty well as long as you don't \nintroduce these kinds of issues by hand. For now, -f is the only \nreasonable thing to do.\n\nWill we fix it? I suspect we will teach git about these kinds of name \naliases some day, but most of the git developers avoid broken filesystems, \nand the ones that are on broken filesystems tend to avoid having the same \nname in different cases, so it's not exactly a high priority.\n\nIt's actually nontrivial to get right and test (on sane filesystems).\n\nI could probably whip up something that gets US-ASCII right for this \nparticular case (ie just switching between branches) reasonably easily (ie \ndo a pretty stupid \"works for the common case\" thing without even trying \nto be anythign else). I just really haven't had a lot of motivation to do \nit. Let's see if I can get the energy..\n\n\t\tLinus\n"},{"id":"72606","messageId":"32541b130803211057h22310557ne605e39e6b894e11@mail.gmail.com","threadId":"12794","inReplyTo":"alpine.LFD.1.00.0803211037160.3020@woody.linux-foundation.org","subject":"Re: Cygwin: problem with renaming and case","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-03-21T17:57:42Z","receivedAt":"2008-03-21T17:57:42Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, Mar 21, 2008 at 1:46 PM, Linus Torvalds\n<torvalds@linux-foundation.org> wrote:\n>  Now, you're tracking \"Aaa.txt\" in the branch you're leaving, and git knows\n>  that, but git also knows that the branch you're leaving is *not* tracking\n>  \"aaa.txt\", so obviously the copy of \"aaa.txt\" that the filesystem reports\n>  is not saved anywhere, and git says \"I refuse to overwrite it, because\n>  that would destroy your untracked content\".\n\nI don't know if this helps, but if git would delete the files it's\nplanning to forget before checking the existence of files it's\nplanning to create, case sensitivity problems like these would\nautomatically disappear and you wouldn't have to worry about case (and\naccent, and and...) folding by hand.\n\nUnfortunately, that would mean git is changing things around before it\ncan safely make a decision about whether that's a good idea.  That\nsaid, it would be possible to put things back, since it knows the\nfiles it deleted are stored safely in the original branch anyway.\n\nHave fun,\n\nAvery\n"},{"id":"72607","messageId":"alpine.LFD.1.00.0803211105190.3020@woody.linux-foundation.org","threadId":"12794","inReplyTo":"32541b130803211057h22310557ne605e39e6b894e11@mail.gmail.com","subject":"Re: Cygwin: problem with renaming and case","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-03-21T18:09:56Z","receivedAt":"2008-03-21T18:09:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 21 Mar 2008, Avery Pennarun wrote:\n> \n> I don't know if this helps, but if git would delete the files it's \n> planning to forget before checking the existence of files it's planning \n> to create, case sensitivity problems like these would automatically \n> disappear and you wouldn't have to worry about case (and accent, and \n> and...) folding by hand.\n\nYeah, but the whole logic of git-read-tree (which is what does this all) \nis to verify everything is up-to-date and a-ok before doing anything to \nyour filesystem. Which is just a good idea in general.\n\nBasically, we don't want to do something part-way, and then notice later \nthat \"oh, but..\" and have to try to undo the thing we did partially.\n\nSo I agree, in this case the \"remove files that go away first\" would work \naround the problem, and we could look into whether that is reasonable in \nsome cases, but in general it's not trivial either.\n\nMy personal guess is that it's probably better to start teaching git about \ncase-broken filesystem, even if we start it with some common special case \nrather than getting every case right from the beginning.\n\n\t\tLinus\n"},{"id":"72613","messageId":"37fcd2780803211157n15cec620gb5ab1d3e57ccd37b@mail.gmail.com","threadId":"12794","inReplyTo":"47E3DD28.4030302@tiscali.it","subject":"Re: Cygwin: problem with renaming and case","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-03-21T18:57:05Z","receivedAt":"2008-03-21T18:57:05Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, Mar 21, 2008 at 7:07 PM, Frank <streamlake@tiscali.it> wrote:\n> Hi,\n>  Don't know exactly if this is a bug or a feature or something in the\n>  middle, but I have a lot of problems while changing just the casing of\n>  file names and using git mv und cygwin. Here's a test case:\n>\n>  mkdir testrename\n>  cd testrename\n>  git init\n>  echo \"AAA\" >aaa.txt\n>  echo \"BBB\" >bbb.txt\n>  git add aaa.txt\n>  git add bbb.txt\n>  git commit -m \"First commit\"\n>  git checkout -b new_branch\n>  git mv aaa.txt ccc.txt\n>  git commit -a -m \"Moved file\"\n>  echo \"NEW AAA\" >Aaa.txt\n>  git add Aaa.txt\n>  git commit -m \"Added Aaa\"\n>  #aaa.txt exists in master, Aaa.txt in new_branch\n>  git checkout master\n\nI wonder do you really need to have two files on different branches whose\nname only differ by case, especially when you work on case insensitive\nfilesystem? I suspect the answer is no. In this case, you can choose one\npolicy for file naming and stick to it. For instance, that all names should\nbe in low case except Makefile, or something like that. This policy can be\nenforced using pre-commit hook.\n\nDmitry\n"},{"id":"72615","messageId":"47E40E8C.9040805@tiscali.it","threadId":"12794","inReplyTo":"37fcd2780803211157n15cec620gb5ab1d3e57ccd37b@mail.gmail.com","subject":"Re: Cygwin: problem with renaming and case","fromName":"","fromEmail":"streamlake@tiscali.it","sentAt":"2008-03-21T19:37:48Z","receivedAt":"2008-03-21T19:37:48Z","isPatch":false,"sender":{"key":"streamlake@tiscali.it","avatar":null},"body":"Dmitry Potapov ha scritto:\n>\n>\n> I wonder do you really need to have two files on different branches whose\n> name only differ by case, especially when you work on case insensitive\n> filesystem? I suspect the answer is no. In this case, you can choose one\n> policy for file naming and stick to it. For instance, that all names should\n> be in low case except Makefile, or something like that. This policy can be\n> enforced using pre-commit hook.\n>\n> Dmitry\n>\n>   \n\nYou're right, in fact it usually happens as the result of a mistake in \nnaming a file between two branches or deleting a file and creating \nanother one months later with the same name, not really a question of \npolicies... :-)\n\n@Linus\nAs always, I'm absolutely not a windz fan (and this is demonstrated by \nthe fact that I've been using cygwin for long time instead of the crappy \nwin command prompt, and use linux every day for a few non-strictly-windz \nprojects), but I 'must' use it if I want to work, there's no choice \nwhere I come from, and I can't change the market by myself, even if I \nstrongly support linux as a substitute...\nSo, given the fact that git is almost 'officially' supported at least \nunder cygwin, I think it would be a good idea, if technically possible, \nto have a look at this kind of features. Not to mention the fact that \nhaving a broader audience for a project like git can be positive...\n\nThanks for your help,\nFrank\n"},{"id":"72617","messageId":"47E41290.71E84739@dessent.net","threadId":"12794","inReplyTo":"47E40E8C.9040805@tiscali.it","subject":"Re: Cygwin: problem with renaming and case","fromName":"Brian Dessent","fromEmail":"brian@dessent.net","sentAt":"2008-03-21T19:54:56Z","receivedAt":"2008-03-21T19:54:56Z","isPatch":false,"sender":{"key":"brian@dessent.net","avatar":null},"body":"streamlake@tiscali.it wrote:\n\n> So, given the fact that git is almost 'officially' supported at least\n> under cygwin, I think it would be a good idea, if technically possible,\n> to have a look at this kind of features. Not to mention the fact that\n\nYou can use a Cygwin managed mount if you really need case sensitivity.\n\nBrian\n"},{"id":"72632","messageId":"7vtzizmwd4.fsf@gitster.siamese.dyndns.org","threadId":"12794","inReplyTo":"alpine.LFD.1.00.0803211105190.3020@woody.linux-foundation.org","subject":"Re: Cygwin: problem with renaming and case","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-22T00:32:39Z","receivedAt":"2008-03-22T00:32:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> So I agree, in this case the \"remove files that go away first\" would work \n> around the problem, and we could look into whether that is reasonable in \n> some cases, but in general it's not trivial either.\n\nI think we have two phase \"remove then create\" in git-apply for an\nentirely different reason (we do check before doing any removal or\ncreation).\n\n> My personal guess is that it's probably better to start teaching git about \n> case-broken filesystem, even if we start it with some common special case \n> rather than getting every case right from the beginning.\n\nHmm.  I have to say I am not very enthused by the prospect, as I agree\nwith your reasoning in your earlier message why this has been lower\npriority (\"sane people when forced to use case corrupting systems avoid\nproblematic paths to make this a non-issue anyway\").  My feeling is that\nthis falls into the \"when we are bored to death and have absolutely\nnothing better to do\" category.\n"},{"id":"72659","messageId":"alpine.OSX.1.00.0803221429390.7656@cougar","threadId":"12794","inReplyTo":"7vtzizmwd4.fsf@gitster.siamese.dyndns.org","subject":"Re: Cygwin: problem with renaming and case","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-03-22T13:45:52Z","receivedAt":"2008-03-22T13:45:52Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"On Fri, 21 Mar 2008, Junio C Hamano wrote:\n\n> Linus Torvalds <torvalds@linux-foundation.org> writes:\n> \n> > My personal guess is that it's probably better to start teaching git about \n> > case-broken filesystem, even if we start it with some common special case \n> > rather than getting every case right from the beginning.\n> \n> Hmm.  I have to say I am not very enthused by the prospect, as I agree\n> with your reasoning in your earlier message why this has been lower\n> priority (\"sane people when forced to use case corrupting systems avoid\n> problematic paths to make this a non-issue anyway\").  My feeling is that\n> this falls into the \"when we are bored to death and have absolutely\n> nothing better to do\" category.\n\nSane people might be forced to modify paths in a problematic way more\noften than you think.  A common error I see in practice is that\na developer introduces a typo when adding a new header file on\na \"case-broken\" filesystem.  A typo that only introduces a different\ncase in the filename and the matching #include statement is\nunrecognizable on a \"case-broken\" filesystem.  The compiler will find\nthe file regardless of the different case in the include statement.\nOnly when the source is checked out on a case-sensitive filesystem the\nerror is recognized and needs to be fixed.  The lucky case is if the\ntypo is in the #include statement.  The problematic case is if the case\nof the filename wrong (violates the coding style of the project).  In\nthe latter case the file needs to be renamed to a path that only differs\nin case, which triggers the problem.\n\n            Steffen\n"},{"id":"72701","messageId":"47E564F5.6010005@iksz.hu","threadId":"12794","inReplyTo":"37fcd2780803211157n15cec620gb5ab1d3e57ccd37b@mail.gmail.com","subject":"Re: Cygwin: problem with renaming and case","fromName":"Nagy Balázs","fromEmail":"js@iksz.hu","sentAt":"2008-03-22T19:58:45Z","receivedAt":"2008-03-22T19:58:45Z","isPatch":false,"sender":{"key":"js@iksz.hu","avatar":"https://gravatar.com/avatar/8e618db1f4a022c12a6f0cd5a9632663f61afd781108fdf32f2433589b1901b8?d=mp&s=160"},"body":"Dmitry Potapov wrote:\n> I wonder do you really need to have two files on different branches whose\n> name only differ by case, especially when you work on case insensitive\n> filesystem? I suspect the answer is no. In this case, you can choose one\n> policy for file naming and stick to it. For instance, that all names should\n> be in low case except Makefile, or something like that. This policy can be\n> enforced using pre-commit hook.\n>   \n\nqmail-1.03 is one of the rare species which has two files which differ \nonly in their case, namely INSTALL and install.  The first one contains \nthe documentation, the latter one is compiled from source.  Apart from \nthat I don't know any other affected projects.\n\nOn the other hand, most of the software developers are morons, \nespecially in a corporate environment.  The problem is you cannot refuse \ntheir work all the way, and they like to create evil twins (file names \nwhich were removed and added again), and case collisions.  I could even \nsee a lot of symlinks in a clearcase vob which poined to \n`..\\..\\..\\../a/b/c'.  Developer stupidity is unlimited.\n\nRegards,\n-- \n-jul-\n"},{"id":"72702","messageId":"alpine.LFD.1.00.0803221312010.3020@woody.linux-foundation.org","threadId":"12794","inReplyTo":"47E564F5.6010005@iksz.hu","subject":"Re: Cygwin: problem with renaming and case","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-03-22T20:18:10Z","receivedAt":"2008-03-22T20:18:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 22 Mar 2008, Nagy Bal?zs wrote:\n> \n> qmail-1.03 is one of the rare species which has two files which differ only in\n> their case, namely INSTALL and install.  The first one contains the\n> documentation, the latter one is compiled from source.  Apart from that I\n> don't know any other affected projects.\n\nThe kernel has lots of them. Well, not \"lots\" (considering that it has \n23000+ filenames), but something like 20+ names that exists in two forms \nwith just different case.\n\nDo\n\n\tgit ls-files | tr '[A-Z]' '[a-z]' | sort | uniq -d\n\nand you'll get\n\n\tinclude/linux/netfilter_ipv4/ipt_connmark.h\n\tinclude/linux/netfilter_ipv4/ipt_dscp.h\n\tinclude/linux/netfilter_ipv4/ipt_ecn.h\n\tinclude/linux/netfilter_ipv4/ipt_mark.h\n\tinclude/linux/netfilter_ipv4/ipt_tcpmss.h\n\tinclude/linux/netfilter_ipv4/ipt_tos.h\n\tinclude/linux/netfilter_ipv4/ipt_ttl.h\n\tinclude/linux/netfilter_ipv6/ip6t_hl.h\n\tinclude/linux/netfilter_ipv6/ip6t_mark.h\n\tinclude/linux/netfilter/xt_connmark.h\n\tinclude/linux/netfilter/xt_dscp.h\n\tinclude/linux/netfilter/xt_mark.h\n\tinclude/linux/netfilter/xt_rateest.h\n\tinclude/linux/netfilter/xt_tcpmss.h\n\tnet/ipv4/netfilter/ipt_ecn.c\n\tnet/ipv4/netfilter/ipt_ttl.c\n\tnet/ipv6/netfilter/ip6t_hl.c\n\tnet/netfilter/xt_connmark.c\n\tnet/netfilter/xt_dscp.c\n\tnet/netfilter/xt_mark.c\n\tnet/netfilter/xt_rateest.c\n\tnet/netfilter/xt_tcpmss.c\n\nwhere you basically have the netfilter people using lower-case version for \nnetfilter matching rules and the uppercase vesion for rewriting rules. Or \nsomething.\n\nAdmittedly the netfilter people _are_ strange, and we need to make sure \nthat they take all their medication regularly or they do stupid things, \nbut it does happen. The kernel people obviously expect people to use sane \nfilesystems for kernel development..\n\n\t\t\tLinus\n"}]}