threads / discuss / 40242

Windows path handling changed between versions

Subject: Windows path handling changed between versions

## tl;dr

3 messages between Sep 1, 2015 and Sep 1, 2015.

replies: 2people: 2as markdown or json

Geofrey Sanders· Sep 1, 2015, 16:55 UTC · lore
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· Sep 1, 2015, 17:30 UTC · re: Geofrey Sanders · lore

Re: Windows path handling changed between versions

Hi Geofrey,
On 2015-09-01 18:55, Geofrey Sanders wrote:
Show 10 quoted lines
> 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?
Show 6 quoted lines
> 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.
Show 11 quoted lines
> 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· Sep 1, 2015, 19:10 UTC · re: Johannes Schindelin · lore

Re: Windows path handling changed between versions

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 <johannes.schindelin@gmx.de> wrote:

Show 56 quoted lines
> 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

← back to recent threads