{"thread":{"id":"40242","subject":"Windows path handling changed between versions","startedAt":"2015-09-01T16:55:38Z","lastAt":"2015-09-01T19:10:01Z","messageCount":3,"participants":["Geofrey Sanders","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"269104","messageId":"CAFPYLHASH_LZ2YgQWjfPKCwq_n-9HVNotkimiQDY1Qy8_8gtwg@mail.gmail.com","threadId":"40242","inReplyTo":null,"subject":"Windows path handling changed between versions","fromName":"Geofrey Sanders","fromEmail":"geofrey.sanders@gmail.com","sentAt":"2015-09-01T16:55:38Z","receivedAt":"2015-09-01T16:55:38Z","isPatch":false,"sender":{"key":"geofrey.sanders@gmail.com","avatar":null},"body":"I recently upgraded from Windows Git 1.6.2 to 2.5.0 and found myself\nunable to rebase. Turns out paths didn't used to be case-sensitive and\nnow they are, causing a number of operations to halt. A repo created\nby pointing at the directory\n    c:\\core\\guidewire\\Dev\\2.4\nwould (I suppose) technically have been invalid the whole time because\nWindows reports the current path as\n    C:\\core\\guidewire\\Dev\\2.4\n, but msys Git 1.6.2 evidently made a case-insensitive path comparison\nso the discrepancy was suppressed.\n\nThe proximate cause of errors was\n    git rev-parse --is-inside-work-tree\nwhich would output 'false' even inside the working tree.\n\"--is-inside-git-dir\" also printed 'false' in directories where it\nshould have said 'true'. I actually missed the problem in plain sight\nat first, because I created a new repo (in which everything worked as\nexpected), and then did a directory diff... the worktree paths were\ndifferent but I only noticed the names, not the case difference in the\ndrive letter. More details in this SO question:\nhttp://stackoverflow.com/q/32280644/2835086\n\nI was able to repair my existing repos by changing the 'worktree'\nvalue in gitconfig - s/c/C/ did the trick - but the whole thing was a\nsurprise.\n\nIs this a bug in the current version? Windows doesn't distinguish on\ncase, so maybe applications shouldn't either.\nWas this a bug in the prior version? Maybe creating a repo with a\nworktree path that doesn't match the file system should have been an\nerror from the very beginning.\nWas this user error? Maybe I did something wrong and should have known\nbetter, but got away with it for a while.\n\nAny feedback welcome,\n-gws\n"},{"id":"269109","messageId":"d2bd100f23980ace0ec9f071fbe18add@www.dscho.org","threadId":"40242","inReplyTo":"CAFPYLHASH_LZ2YgQWjfPKCwq_n-9HVNotkimiQDY1Qy8_8gtwg@mail.gmail.com","subject":"Re: Windows path handling changed between versions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-09-01T17:30:49Z","receivedAt":"2015-09-01T17:30:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Geofrey,\n\nOn 2015-09-01 18:55, Geofrey Sanders wrote:\n> I recently upgraded from Windows Git 1.6.2 to 2.5.0 and found myself\n> unable to rebase. Turns out paths didn't used to be case-sensitive and\n> now they are, causing a number of operations to halt. A repo created\n> by pointing at the directory\n>     c:\\core\\guidewire\\Dev\\2.4\n> would (I suppose) technically have been invalid the whole time because\n> Windows reports the current path as\n>     C:\\core\\guidewire\\Dev\\2.4\n> , but msys Git 1.6.2 evidently made a case-insensitive path comparison\n> so the discrepancy was suppressed.\n\nAre you sure about that? I seem to recall that `pwd` changed behavior between MSys and MSys2, but Git never made case-insensitive comparisons.\n\nIt 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?\n\n> The proximate cause of errors was\n>     git rev-parse --is-inside-work-tree\n> which would output 'false' even inside the working tree.\n\nAh, you are apparently talking about a worktree separate from your repository?\n\n> \"--is-inside-git-dir\" also printed 'false' in directories where it\n> should have said 'true'.\n\nAgain, 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?\n\n> I actually missed the problem in plain sight\n> at first, because I created a new repo (in which everything worked as\n> expected), and then did a directory diff... the worktree paths were\n> different but I only noticed the names, not the case difference in the\n> drive letter. More details in this SO question:\n> http://stackoverflow.com/q/32280644/2835086\n\nPlease 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.\n\nSo 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.\n\n> I was able to repair my existing repos by changing the 'worktree'\n> value in gitconfig - s/c/C/ did the trick - but the whole thing was a\n> surprise.\n> \n> Is this a bug in the current version? Windows doesn't distinguish on\n> case, so maybe applications shouldn't either.\n> Was this a bug in the prior version? Maybe creating a repo with a\n> worktree path that doesn't match the file system should have been an\n> error from the very beginning.\n> Was this user error? Maybe I did something wrong and should have known\n> better, but got away with it for a while.\n\nI 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.\n\nLooking forward to more detailed information and that MCVE,\nJohannes\n"},{"id":"269144","messageId":"CAJ6Pf+SzzPTw8ycJe8Y0W=xM8iHYU4r=nyTA5bPdhyyLKgVLDQ@mail.gmail.com","threadId":"40242","inReplyTo":"d2bd100f23980ace0ec9f071fbe18add@www.dscho.org","subject":"Re: Windows path handling changed between versions","fromName":"Geofrey Sanders","fromEmail":"geofrey.sanders@gmail.com","sentAt":"2015-09-01T19:10:01Z","receivedAt":"2015-09-01T19:10:01Z","isPatch":false,"sender":{"key":"geofrey.sanders@gmail.com","avatar":null},"body":"I can (eventually) make a proper bug report,in the mean time I'll\naddress a few particulars:\n* I've been using git from regular CMD with Git's bin/ in my path. Not Git Bash.\n* I created a new repo by cloning, giving an absolute path for the\nworking tree location. This is the line from the script I used:\n    git clone --separate-git-dir c:\\dev\\git\\%branch% -o MAIN\nc:\\core\\guidewire\\MAIN c:\\core\\guidewire\\%branch%\n** Yes, the working tree and gitdir are in separate locations. (I\ndon't think this would have made a difference.)\n* I verified the case-sensitivity problem by comparing cd-ing (in\nregular CMD) to absolute paths with upper- and lower-case drive\nletters. Starting with 'C' made the rev-parse predicates give the\nexpected answers.\n\nIt was not my intention to drop a bunch of work on you or anyone; I'm\nsorry it sounded that way! I started out with an email here on the\nadvice of https://git-scm.com/community. Day-job permitting, I'll\nreinstall 1.6.2 and determine the minimum steps to demonstrate the\nproblem as I originally observed it. When I've got reproducible test\nsteps, should I open a bug on Github, or come back here?\n\nAnd finally, if you tell me outright this was all my own fault for\ntyping the paths wrongly I won't be offended : )\n\n-gws\n\n\n\nOn Tue, Sep 1, 2015 at 1:30 PM, Johannes Schindelin\n<johannes.schindelin@gmx.de> wrote:\n> Hi Geofrey,\n>\n> On 2015-09-01 18:55, Geofrey Sanders wrote:\n>> I recently upgraded from Windows Git 1.6.2 to 2.5.0 and found myself\n>> unable to rebase. Turns out paths didn't used to be case-sensitive and\n>> now they are, causing a number of operations to halt. A repo created\n>> by pointing at the directory\n>>     c:\\core\\guidewire\\Dev\\2.4\n>> would (I suppose) technically have been invalid the whole time because\n>> Windows reports the current path as\n>>     C:\\core\\guidewire\\Dev\\2.4\n>> , but msys Git 1.6.2 evidently made a case-insensitive path comparison\n>> so the discrepancy was suppressed.\n>\n> Are you sure about that? I seem to recall that `pwd` changed behavior between MSys and MSys2, but Git never made case-insensitive comparisons.\n>\n> 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?\n>\n>> The proximate cause of errors was\n>>     git rev-parse --is-inside-work-tree\n>> which would output 'false' even inside the working tree.\n>\n> Ah, you are apparently talking about a worktree separate from your repository?\n>\n>> \"--is-inside-git-dir\" also printed 'false' in directories where it\n>> should have said 'true'.\n>\n> 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?\n>\n>> I actually missed the problem in plain sight\n>> at first, because I created a new repo (in which everything worked as\n>> expected), and then did a directory diff... the worktree paths were\n>> different but I only noticed the names, not the case difference in the\n>> drive letter. More details in this SO question:\n>> http://stackoverflow.com/q/32280644/2835086\n>\n> 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.\n>\n> 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.\n>\n>> I was able to repair my existing repos by changing the 'worktree'\n>> value in gitconfig - s/c/C/ did the trick - but the whole thing was a\n>> surprise.\n>>\n>> Is this a bug in the current version? Windows doesn't distinguish on\n>> case, so maybe applications shouldn't either.\n>> Was this a bug in the prior version? Maybe creating a repo with a\n>> worktree path that doesn't match the file system should have been an\n>> error from the very beginning.\n>> Was this user error? Maybe I did something wrong and should have known\n>> better, but got away with it for a while.\n>\n> 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.\n>\n> Looking forward to more detailed information and that MCVE,\n> Johannes\n"}]}