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 -- 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