Re: Unexpected ignorecase=false behavior on Windows

From: Marc Strapetz <marc.strapetz@syntevo.com>
Date: Jun 22, 2018, 20:45 UTC
Message-ID: <2cf2d884-de1a-7b9b-5aca-1f396ad205a2@syntevo.com>
In-Reply-To: <1c7e338e-157b-fd2f-5eb1-01373f627acd@kdbg.org>

On 22.06.2018 19:36, Johannes Sixt wrote:

Show 20 quoted lines

> 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