Re: Unexpected ignorecase=false behavior on Windows

From: Bryan Turner <bturner@atlassian.com>
Date: Jun 22, 2018, 20:58 UTC
Message-ID: <CAGyf7-GvcN8EhMgtaZcDJNYNdfLwVH8HVBDmZqJU40nze0NSEA@mail.gmail.com>
In-Reply-To: <2cf2d884-de1a-7b9b-5aca-1f396ad205a2@syntevo.com>

On Fri, Jun 22, 2018 at 1:45 PM Marc Strapetz <marc.strapetz@syntevo.com> wrote:

Show 33 quoted lines

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

Show 27 quoted lines

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