Uper/lower Case files extension

Description

As HTML is Case sensitive for images names, if I change a pic’s extension from JPG to jpg, GitHub desktop app doesn’t seems to update the difference and do not ask for git push update. PS: I would like so much to work for you. If you have any job to give to me, do not hesitate I would be fully committed

Version

GitHub Desktop version: [0.8.0.0]

OS version: [windows 10 x64]

Steps to Reproduce

1. [Change extension on desktop explorer from JPG to jpg]
2. [Open Git Desktop]
3. [Doesn’t seems to update files extension in order to push it to server]

Expected behavior: [Propose to commit to master]

Actual behavior: [No change shown]

Reproduces how often: [it reproduce 100% of time definitely]

Logs

Additional Information

[shiftkey]

@GregoireSailland thanks for the extra details.

This behaviour is driven from Git’s core.ignorecase config value:

If true, this option enables various workarounds to enable Git to work better on filesystems that are not case sensitive, like FAT. For example, if a directory listing finds “makefile” when Git expects “Makefile”, Git will assume it is really the same file, and continue to remember it as “Makefile”.

The default is false, except git-clone or git-init will probe and set core.ignoreCase true if appropriate when the repository is created.

A quick test of this indicates Git 2.14.1 will set this to true within the repository (rather than globally):

$ git --version
git version 2.14.1.windows.1
$ git init test-core-ignorecase
Initialized empty Git repository in C:/Users/shiftkey/src/test-core-ignorecase/.git/
$ cd test-core-ignorecase/
$ git config --show-origin core.ignorecase
file:.git/config        true

So while you could set core.ignorecase to false, there’s also known limitations that Git is probing for. From the Wikipedia article about filesystems:

While NTFS itself supports case sensitivity, the Win32 environment subsystem cannot create files whose names differ only by case for compatibility reasons. When a file is opened for writing, if there is any existing file whose name is a case-insensitive match for the new file, the existing file is truncated and opened for writing instead of a new file with a different name being created. Other subsystems like e. g. Services for Unix, that operate directly above the kernel and not on top of Win32 can have case-sensitivity.

macOS also suffers from the same limitation, but it occurs in a slightly different way:

Although often believed to be case sensitive, HFS Plus normally is not. The typical default installation is case-preserving only. From Mac OS X 10.3 on the command newfs_hfs -s will create a case-sensitive new file system. HFS Plus version 5 optionally supports case-sensitivity. However, since case-sensitivity is fundamentally different from case-insensitivity, a new signature was required so existing HFS Plus utilities would not see case-sensitivity as a file system error that needed to be corrected.

Anyway, hope that gives some insight. You _could_try and set core.ignorecase=false to see if it works, but I think you’re gonna have a bad time elsewhere. For example, this README.md file was already tracked by Git, but renaming it to README.MD meant Git then considers it an untracked file:

$ ls
README.md
$ mv README.md README.MD
$ ls
README.MD
$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        README.MD

nothing added to commit but untracked files present (use "git add" to track)

[ethomson]

👋 I’m crashing your issues since I tweeted about something similar.

As HTML is Case sensitive for images names, if I change a pic’s extension from JPG to jpg, GitHub desktop app doesn’t seems to update the difference and do not ask for git push update.

This is the correct behavior. This is because some tools do stupid things and will accidentally rewrite a file with a different filename (differing in case only). Some programs will do things like write to a lock file and then move it into place. eg, when editing a file named FOO.txt, they will create foo.txt.lock and then move that to foo.txt. They make big assumptions about their ability to do this in the case sensitivity of the underlying filesystem.

This is a bummer, but it would be terrible for a version control system to flip-flop the case of a filename based on a broken tool.

Similarly, GitHub Desktop should not detect that a filename’s case has changed (when running on a case insensitive filesystem).

A quick test of this indicates Git 2.14.1 will set this to true within the repository (rather than globally).

Yep, this is true. This is examined and detected when you create a repository (either via git init or git clone). You could have different filesystems mounted with different case sensitivity. For example: you could have a FAT32 USB key on your Linux box that otherwise uses ext3 with case sensitive filesystems. So this is done on a per-repository basis.

(Having a git repository span multiple filesystems with different case sensitivity characteristics would not be supported.)

To be very clear: this is a cache of the underlying characteristics of the filesystem. Detecting whether a filesystem is case sensitive or not is slow - it requires writing a file and reading it back in (with a different filename). Git does not want to do this detection every time you run a Git command, so it detects it when the repository is created and caches it.

This is not an option that you can change.

If your filesystem is case insensitive, then Git will behave this way. If you want to perform a case-changing rename (change a filename’s case only) then you need to explicitly tell Git to track the new filename:

git mv FOO.txt foo.txt