# Windows path handling changed between versions 3 messages from 2015-09-01 to 2015-09-01. Participants: Geofrey Sanders, Johannes Schindelin. Thread: https://gitlist.dev/t/40242 ## Geofrey Sanders, 2015-09-01 16:55 Subject: Windows path handling changed between versions Message-ID: URL: https://gitlist.dev/e/CAFPYLHASH_LZ2YgQWjfPKCwq_n-9HVNotkimiQDY1Qy8_8gtwg%40mail.gmail.com ``` I recently upgraded from Windows Git 1.6.2 to 2.5.0 and found myself unable to rebase. Turns out paths didn't used to be case-sensitive and now they are, causing a number of operations to halt. A repo created by pointing at the directory c:\core\guidewire\Dev\2.4 would (I suppose) technically have been invalid the whole time because Windows reports the current path as C:\core\guidewire\Dev\2.4 , but msys Git 1.6.2 evidently made a case-insensitive path comparison so the discrepancy was suppressed. The proximate cause of errors was git rev-parse --is-inside-work-tree which would output 'false' even inside the working tree. "--is-inside-git-dir" also printed 'false' in directories where it should have said 'true'. I actually missed the problem in plain sight at first, because I created a new repo (in which everything worked as expected), and then did a directory diff... the worktree paths were different but I only noticed the names, not the case difference in the drive letter. More details in this SO question: http://stackoverflow.com/q/32280644/2835086 I was able to repair my existing repos by changing the 'worktree' value in gitconfig - s/c/C/ did the trick - but the whole thing was a surprise. Is this a bug in the current version? Windows doesn't distinguish on case, so maybe applications shouldn't either. Was this a bug in the prior version? Maybe creating a repo with a worktree path that doesn't match the file system should have been an error from the very beginning. Was this user error? Maybe I did something wrong and should have known better, but got away with it for a while. Any feedback welcome, -gws ``` ## Johannes Schindelin, 2015-09-01 17:30 Subject: Re: Windows path handling changed between versions Message-ID: URL: https://gitlist.dev/e/d2bd100f23980ace0ec9f071fbe18add%40www.dscho.org In-Reply-To: ``` Hi Geofrey, On 2015-09-01 18:55, Geofrey Sanders wrote: > I recently upgraded from Windows Git 1.6.2 to 2.5.0 and found myself > unable to rebase. Turns out paths didn't used to be case-sensitive and > now they are, causing a number of operations to halt. A repo created > by pointing at the directory > c:\core\guidewire\Dev\2.4 > would (I suppose) technically have been invalid the whole time because > Windows reports the current path as > C:\core\guidewire\Dev\2.4 > , but msys Git 1.6.2 evidently made a case-insensitive path comparison > so the discrepancy was suppressed. Are you sure about that? I seem to recall that `pwd` changed behavior between MSys and MSys2, but Git never made case-insensitive comparisons. It might help me to understand what is going on if I could have preciser information. What exactly do you mean by "A repo created by pointing at ..."? Could you type out the Git commands you used? > The proximate cause of errors was > git rev-parse --is-inside-work-tree > which would output 'false' even inside the working tree. Ah, you are apparently talking about a worktree separate from your repository? > "--is-inside-git-dir" also printed 'false' in directories where it > should have said 'true'. Again, I really need preciser information about this: *How* did you end up in that directory? Did you use Git Bash or Git CMD? Did you call `cd` with a relative path, a POSIX path or a POSIX-ified full DOS path? > I actually missed the problem in plain sight > at first, because I created a new repo (in which everything worked as > expected), and then did a directory diff... the worktree paths were > different but I only noticed the names, not the case difference in the > drive letter. More details in this SO question: > http://stackoverflow.com/q/32280644/2835086 Please understand that I have a lot of tickets to juggle about and that it is a bit unfair to send me onto a goose chase. I would have preferred a proper GitHub issue, as the "Contribute" section of https://git-for-windows.github.io/ explicitly asks for, but I am okay with discussing this ticket on the mailing list. But studying a StackOverflow thread in addition is a bit much... next, people would ask me to search their Twitter feed for the little tid bit of information I need to help. So please summarize that StackOverflow question, and while we are at it: StackOverflow suggests coming up with a Minimal, Complete and Verifiable Example. That would be a nice thing to have. Maybe you find it in you to come up with that MCVE. > I was able to repair my existing repos by changing the 'worktree' > value in gitconfig - s/c/C/ did the trick - but the whole thing was a > surprise. > > Is this a bug in the current version? Windows doesn't distinguish on > case, so maybe applications shouldn't either. > Was this a bug in the prior version? Maybe creating a repo with a > worktree path that doesn't match the file system should have been an > error from the very beginning. > Was this user error? Maybe I did something wrong and should have known > better, but got away with it for a while. I think there is a good chance we can fix this, although a 1.x -> 2.x jump always suggests that certain things change in a backwards-incompatible manner. Looking forward to more detailed information and that MCVE, Johannes ``` ## Geofrey Sanders, 2015-09-01 19:10 Subject: Re: Windows path handling changed between versions Message-ID: URL: https://gitlist.dev/e/CAJ6Pf%2BSzzPTw8ycJe8Y0W%3DxM8iHYU4r%3DnyTA5bPdhyyLKgVLDQ%40mail.gmail.com In-Reply-To: ``` I can (eventually) make a proper bug report,in the mean time I'll address a few particulars: * I've been using git from regular CMD with Git's bin/ in my path. Not Git Bash. * I created a new repo by cloning, giving an absolute path for the working tree location. This is the line from the script I used: git clone --separate-git-dir c:\dev\git\%branch% -o MAIN c:\core\guidewire\MAIN c:\core\guidewire\%branch% ** Yes, the working tree and gitdir are in separate locations. (I don't think this would have made a difference.) * I verified the case-sensitivity problem by comparing cd-ing (in regular CMD) to absolute paths with upper- and lower-case drive letters. Starting with 'C' made the rev-parse predicates give the expected answers. It was not my intention to drop a bunch of work on you or anyone; I'm sorry it sounded that way! I started out with an email here on the advice of https://git-scm.com/community. Day-job permitting, I'll reinstall 1.6.2 and determine the minimum steps to demonstrate the problem as I originally observed it. When I've got reproducible test steps, should I open a bug on Github, or come back here? And finally, if you tell me outright this was all my own fault for typing the paths wrongly I won't be offended : ) -gws On Tue, Sep 1, 2015 at 1:30 PM, Johannes Schindelin wrote: > Hi Geofrey, > > On 2015-09-01 18:55, Geofrey Sanders wrote: >> I recently upgraded from Windows Git 1.6.2 to 2.5.0 and found myself >> unable to rebase. Turns out paths didn't used to be case-sensitive and >> now they are, causing a number of operations to halt. A repo created >> by pointing at the directory >> c:\core\guidewire\Dev\2.4 >> would (I suppose) technically have been invalid the whole time because >> Windows reports the current path as >> C:\core\guidewire\Dev\2.4 >> , but msys Git 1.6.2 evidently made a case-insensitive path comparison >> so the discrepancy was suppressed. > > Are you sure about that? I seem to recall that `pwd` changed behavior between MSys and MSys2, but Git never made case-insensitive comparisons. > > It might help me to understand what is going on if I could have preciser information. What exactly do you mean by "A repo created by pointing at ..."? Could you type out the Git commands you used? > >> The proximate cause of errors was >> git rev-parse --is-inside-work-tree >> which would output 'false' even inside the working tree. > > Ah, you are apparently talking about a worktree separate from your repository? > >> "--is-inside-git-dir" also printed 'false' in directories where it >> should have said 'true'. > > Again, I really need preciser information about this: *How* did you end up in that directory? Did you use Git Bash or Git CMD? Did you call `cd` with a relative path, a POSIX path or a POSIX-ified full DOS path? > >> I actually missed the problem in plain sight >> at first, because I created a new repo (in which everything worked as >> expected), and then did a directory diff... the worktree paths were >> different but I only noticed the names, not the case difference in the >> drive letter. More details in this SO question: >> http://stackoverflow.com/q/32280644/2835086 > > Please understand that I have a lot of tickets to juggle about and that it is a bit unfair to send me onto a goose chase. I would have preferred a proper GitHub issue, as the "Contribute" section of https://git-for-windows.github.io/ explicitly asks for, but I am okay with discussing this ticket on the mailing list. But studying a StackOverflow thread in addition is a bit much... next, people would ask me to search their Twitter feed for the little tid bit of information I need to help. > > So please summarize that StackOverflow question, and while we are at it: StackOverflow suggests coming up with a Minimal, Complete and Verifiable Example. That would be a nice thing to have. Maybe you find it in you to come up with that MCVE. > >> I was able to repair my existing repos by changing the 'worktree' >> value in gitconfig - s/c/C/ did the trick - but the whole thing was a >> surprise. >> >> Is this a bug in the current version? Windows doesn't distinguish on >> case, so maybe applications shouldn't either. >> Was this a bug in the prior version? Maybe creating a repo with a >> worktree path that doesn't match the file system should have been an >> error from the very beginning. >> Was this user error? Maybe I did something wrong and should have known >> better, but got away with it for a while. > > I think there is a good chance we can fix this, although a 1.x -> 2.x jump always suggests that certain things change in a backwards-incompatible manner. > > Looking forward to more detailed information and that MCVE, > Johannes ```