Remote repo filename has different case than local, but no change seen

When I browse to the directory containing a particular file in gitlab, I see TimeHhMM.cs (with the second "M" capitalized).

But in my local repo, the file is TimeHhMm.cs (with the second "m" lower case).

Strangely enough, git does not see this as a change worthy of making it into a commit. Occasionally, some weirdness does pop up that shows there is a problem, though. I just recloned from the origin repo and through a remote pointing to my local filesystem, brought in the branches from my old local repo. git status then showed TimeHhMM.cs deleted--but no TimeHhMm.cs was added. When I discard the deletion and rename the file to the appropriate TimeHhMm.cs, git sees no differences to commit.

That's really weird. Why would it on the one hand detect the file was deleted (case sensitively) but as soon as I bring it back and rename it, it can't detect the "new" file with the lower case "m"?

I can fix this by deleting the file then re-adding it in two separate commits, but it seems there should be some way to cause this action to occur in a single commit. Is there one?

Solution

The behavior is controlled by core.ignoreCase variable. Quoting the docs:

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.

And that was probably the case. You can always reset it to false with the following command:

git config core.ignorecase false

This (quite old) forum thread sheds some light on how exactly probing is done:

As far as I can tell from the code (I obviously only look at the plain vanilla git, and msysgit might have some patch to this part, I dunno. Oh by the way you didn't say which version you are complaining about, either), we do the probing on all systems (including POSIX folks with FAT filesystem mounted) by first creating .git/config and then checking if a file .git/CoNfIg which we know we never created can be accessed. If we can, that means the filesystem ignores case, iow, we cannot have two files config and CoNfIg at the same time, and set core.ignorecase to true.