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
