Unexpected ignorecase=false behavior on Windows

Unexpected ignorecase=false behavior on Windows

[Marc Strapetz]

On Windows, when creating following repository:

$ git init
$ echo "1" > file.txt
$ git add .
$ git commit -m "initial import"
$ ren file.txt File.txt
$ git config core.ignorecase false

Status results are:

$ git status --porcelain
?? File.txt

As on Unix, I would expect to see:

$ git status --porcelain
  D file.txt
?? File.txt

Is the Windows behavior intended? I'm asking, because e.g. JGit will 
report missing files, too, and I'm wondering what would be the correct 
way to resolve this discrepancy? (JGit does not have 
"ignorecase=true"-support at all, btw).

Tested with git version 2.17.1.windows.2

-Marc

Re: Unexpected ignorecase=false behavior on Windows

[Johannes Sixt]

Am 22.06.2018 um 14:04 schrieb Marc Strapetz:
> On Windows, when creating following repository:
> 
> $ git init
> $ echo "1" > file.txt
> $ git add .
> $ git commit -m "initial import"
> $ ren file.txt File.txt
> $ git config core.ignorecase false

This is a user error. core.ignorecase is *not* an instruction as in 
"hey, Git, do not ignore the case of file names". It is better regarded 
as an internal value, with which Git remembers how it should treat the 
names of files that it receives when it traverses the directories on the 
disk.

Git could probe the file system capabilities each time it runs. But that 
would be wasteful. Hence, this probe happens only once when the 
repository is initialized, and the result is recorded in this 
configuration value. You should not change it.

> Status results are:
> 
> $ git status --porcelain
> ?? File.txt
> 
> As on Unix, I would expect to see:
> 
> $ git status --porcelain
>   D file.txt
> ?? File.txt
> 
> Is the Windows behavior intended? I'm asking, because e.g. JGit will 
> report missing files, too, and I'm wondering what would be the correct 
> way to resolve this discrepancy? (JGit does not have 
> "ignorecase=true"-support at all, btw).

Then I don't think there is a way to remove the discrepancy.

-- Hannes

Re: Unexpected ignorecase=false behavior on Windows

[Marc Strapetz]

On 22.06.2018 19:36, Johannes Sixt wrote:
> Am 22.06.2018 um 14:04 schrieb Marc Strapetz:
>> On Windows, when creating following repository:
>>
>> $ git init
>> $ echo "1" > file.txt
>> $ git add .
>> $ git commit -m "initial import"
>> $ ren file.txt File.txt
>> $ git config core.ignorecase false
> 
> This is a user error. core.ignorecase is *not* an instruction as in 
> "hey, Git, do not ignore the case of file names". It is better regarded 
> as an internal value, with which Git remembers how it should treat the 
> names of files that it receives when it traverses the directories on the 
> disk.
> 
> Git could probe the file system capabilities each time it runs. But that 
> would be wasteful. Hence, this probe happens only once when the 
> repository is initialized, and the result is recorded in this 
> configuration value. You should not change it.

Sorry, it looks like my example was misleading. I'm actually questioning 
current behavior in case of Windows repositories with core.ignorecase 
initialized to false, like in following setup:

$ git init
$ git config core.ignorecase false

The repository is now set up to be case-sensitive on Windows. From this 
point on, core.ignorecase won't change anymore and the repository will 
be filled:

$ echo "1" > file.txt
$ git add .
$ git commit -m "initial import"
$ ren file.txt File.txt

Still, status results are:

$ git status --porcelain
?? File.txt

With the same setup sequence on Unix, it's:

$ git status --porcelain
   D file.txt
?? File.txt

Is this difference, which is depending on the platform, intended? Why 
not report missing file.txt as well?

The drawback of the current behavior is that a subsequent "git add ." 
will result in two file names in the .git/index which are only differing 
in case. This will break the repository on Windows, because only one of 
both files can be checked out in the working tree. Also, it makes 
case-only renames harder to be performed.

-Marc

Re: Unexpected ignorecase=false behavior on Windows

[Bryan Turner]

On Fri, Jun 22, 2018 at 1:45 PM Marc Strapetz <marc.strapetz@syntevo.com> wrote:
>
> On 22.06.2018 19:36, Johannes Sixt wrote:
> > Am 22.06.2018 um 14:04 schrieb Marc Strapetz:
> >> On Windows, when creating following repository:
> >>
> >> $ git init
> >> $ echo "1" > file.txt
> >> $ git add .
> >> $ git commit -m "initial import"
> >> $ ren file.txt File.txt
> >> $ git config core.ignorecase false
> >
> > This is a user error. core.ignorecase is *not* an instruction as in
> > "hey, Git, do not ignore the case of file names". It is better regarded
> > as an internal value, with which Git remembers how it should treat the
> > names of files that it receives when it traverses the directories on the
> > disk.
> >
> > Git could probe the file system capabilities each time it runs. But that
> > would be wasteful. Hence, this probe happens only once when the
> > repository is initialized, and the result is recorded in this
> > configuration value. You should not change it.
>
> Sorry, it looks like my example was misleading. I'm actually questioning
> current behavior in case of Windows repositories with core.ignorecase
> initialized to false, like in following setup:
>
> $ git init
> $ git config core.ignorecase false
>
> The repository is now set up to be case-sensitive on Windows. From this
> point on, core.ignorecase won't change anymore and the repository will
> be filled:

I don't think Hannes's point was _when_ you changed it; it was that
you changed it _at all_.

Git on Windows is not designed to run with anything other than
core.ignoreCase=true, and attempting to do so will cause unexpected
behavior. In other words, it's not a behavior toggle so user's can
request the functionality to work one way or the other; it's an
implementation detail that `git init` and `git clone` set when a
repository is created purely so they don't have to probe the file
system each time you run a `git` command.

NTFS is case-preserving-but-case-insensitive by default[1]. So long as
that's the case, the only mode for running Git on Windows is
core.ignoreCase=true.

Hopefully this clarifies things!

Bryan

[1] Windows 10 1803 introduced the ability to set a folder as
case-sensitive[2], but, since it's not inherited automatically by
subdirectories, it still doesn't work well for Git.
[2] https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-directory-case-sensitivity-and-wsl/

>
> $ echo "1" > file.txt
> $ git add .
> $ git commit -m "initial import"
> $ ren file.txt File.txt
>
> Still, status results are:
>
> $ git status --porcelain
> ?? File.txt
>
> With the same setup sequence on Unix, it's:
>
> $ git status --porcelain
>    D file.txt
> ?? File.txt
>
> Is this difference, which is depending on the platform, intended? Why
> not report missing file.txt as well?
>
> The drawback of the current behavior is that a subsequent "git add ."
> will result in two file names in the .git/index which are only differing
> in case. This will break the repository on Windows, because only one of
> both files can be checked out in the working tree. Also, it makes
> case-only renames harder to be performed.
>
> -Marc

Re: Unexpected ignorecase=false behavior on Windows

[Marc Strapetz]

On 22.06.2018 22:58, Bryan Turner wrote:
> On Fri, Jun 22, 2018 at 1:45 PM Marc Strapetz <marc.strapetz@syntevo.com> wrote:
>>
>> On 22.06.2018 19:36, Johannes Sixt wrote:
>>> Am 22.06.2018 um 14:04 schrieb Marc Strapetz:
>>>> On Windows, when creating following repository:
>>>>
>>>> $ git init
>>>> $ echo "1" > file.txt
>>>> $ git add .
>>>> $ git commit -m "initial import"
>>>> $ ren file.txt File.txt
>>>> $ git config core.ignorecase false
>>>
>>> This is a user error. core.ignorecase is *not* an instruction as in
>>> "hey, Git, do not ignore the case of file names". It is better regarded
>>> as an internal value, with which Git remembers how it should treat the
>>> names of files that it receives when it traverses the directories on the
>>> disk.
>>>
>>> Git could probe the file system capabilities each time it runs. But that
>>> would be wasteful. Hence, this probe happens only once when the
>>> repository is initialized, and the result is recorded in this
>>> configuration value. You should not change it.
>>
>> Sorry, it looks like my example was misleading. I'm actually questioning
>> current behavior in case of Windows repositories with core.ignorecase
>> initialized to false, like in following setup:
>>
>> $ git init
>> $ git config core.ignorecase false
>>
>> The repository is now set up to be case-sensitive on Windows. From this
>> point on, core.ignorecase won't change anymore and the repository will
>> be filled:
> 
> I don't think Hannes's point was _when_ you changed it; it was that
> you changed it _at all_.
> 
> Git on Windows is not designed to run with anything other than
> core.ignoreCase=true, and attempting to do so will cause unexpected
> behavior. In other words, it's not a behavior toggle so user's can
> request the functionality to work one way or the other; it's an
> implementation detail that `git init` and `git clone` set when a
> repository is created purely so they don't have to probe the file
> system each time you run a `git` command.
> 
> NTFS is case-preserving-but-case-insensitive by default[1]. So long as
> that's the case, the only mode for running Git on Windows is
> core.ignoreCase=true.
> 
> Hopefully this clarifies things!

Thanks, it does. In this case, I'd suggest to make this clear in the 
documentation, too. I've just sent a patch.

-Marc

Re: Unexpected ignorecase=false behavior on Windows

[Junio C Hamano]

Bryan Turner <bturner@atlassian.com> writes:

> Git on Windows is not designed to run with anything other than
> core.ignoreCase=true, and attempting to do so will cause unexpected
> behavior.

Even though I fully agree with your conclusion that the document
must make it crystal clear that core.ignoreCase must be set to
reflect the reality, I found the above statement misleading and do
not want it to be used as the basis of a documentation update.  But
it is possible that I am misunderstanding the current state of
affairs.

Is the case insensitivity that deeply ingrained in the Git for
Windows code?

IOW, even if the code used to build Git for Windows were executed on
a case sensitive filesystem, is there a case-smashing code on _our_
side that kicks in to cause unexpected behaviour, _even_ when
core.ignorecase is set to false to match (hypothetical) reality?

To put it yet another way, if a case sensitive filesystem were
available, wouldn't running "git init" from Git for Windows in a
directory on such a filesytem set core.ignoreCase to false in the
resulting repository and from then on wouldn't everything work fine?

If my suspicion (i.e. the code for Git for Windows is perfectly
fine---it is just the users are not running with case sensitive
filesystems and flipping core.ignoreCase to true does not make case
incapable filesystems suddenly capable) is correct, then it is not
"Git on Windows is not designed to run" from two angles.  (1) it is
not just Git for Windows---Git running on UNIX that mounts VFAT, or
Git running on macOS with default HFS+, would exhibit the same
symptom, and (2) it is not "Git is not designed to run"---it is
core.ignoreCase that is not designed to be a way to make case
incapable filesystems suddenly capable of distinguishing cases in
filesystems.

Thanks.

Re: Unexpected ignorecase=false behavior on Windows

[Bryan Turner]

On Mon, Jun 25, 2018 at 9:34 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Bryan Turner <bturner@atlassian.com> writes:
>
> > Git on Windows is not designed to run with anything other than
> > core.ignoreCase=true, and attempting to do so will cause unexpected
> > behavior.
>
> Even though I fully agree with your conclusion that the document
> must make it crystal clear that core.ignoreCase must be set to
> reflect the reality, I found the above statement misleading and do
> not want it to be used as the basis of a documentation update.  But
> it is possible that I am misunderstanding the current state of
> affairs.
>
> Is the case insensitivity that deeply ingrained in the Git for
> Windows code?
>
> IOW, even if the code used to build Git for Windows were executed on
> a case sensitive filesystem, is there a case-smashing code on _our_
> side that kicks in to cause unexpected behaviour, _even_ when
> core.ignorecase is set to false to match (hypothetical) reality?
>
> To put it yet another way, if a case sensitive filesystem were
> available, wouldn't running "git init" from Git for Windows in a
> directory on such a filesytem set core.ignoreCase to false in the
> resulting repository and from then on wouldn't everything work fine?
>
> If my suspicion (i.e. the code for Git for Windows is perfectly
> fine---it is just the users are not running with case sensitive
> filesystems and flipping core.ignoreCase to true does not make case
> incapable filesystems suddenly capable) is correct, then it is not
> "Git on Windows is not designed to run" from two angles.  (1) it is
> not just Git for Windows---Git running on UNIX that mounts VFAT, or
> Git running on macOS with default HFS+, would exhibit the same
> symptom, and (2) it is not "Git is not designed to run"---it is
> core.ignoreCase that is not designed to be a way to make case
> incapable filesystems suddenly capable of distinguishing cases in
> filesystems.

Apologies for the unclear word choice. Given Git was designed first to
work with case-sensitive filesystems, certainly the obvious (and
correct) conclusion is that Git itself is fine in a case-sensitive
environment. It wasn't my intention to suggest otherwise.

Note that my word choice was not "Git _for_ Windows", however; it was
"Git _on_ Windows". (This still doesn't change the correctness of your
clarification, let me be quick to add. I'm only pointing it out
because it's relevant to what I intended the comment to say.) On
Windows, the default filesystem is NTFS, and NTFS is not case
sensitive. Hence, Git on Windows (by which I'm implying Git on NTFS),
is not designed to run with anything other than core.ignoreCase=true,
because that setting aligns Git's expectations with how the underlying
filesystem actually works. In other words, Git on a case-insensitive
filesystem (APFS, HFS+, FAT32, exFAT, vFAT, NTFS, etc.) is not
designed to be run with anything other than core.ignoreCase=true.

Bryan

>
> Thanks.