142

I'm not too sure what is going on here, but sometimes a particular file in my repository will change the case of its name. e.g.,:

before: File.h

after: file.h

I don't really care why this is happening, but this causes git to think it is a new file, and then I have to go and change the file name back. Can you just make git ignore case changes?

[edit] I suspect it is Visual Studio doing something weird with that particular file, because it seems to happen most often when I open and save it after changes. I don't have any way to fix bugs in VS however, but git should be a bit more capable I hope.

danronmoon
  • 3,814
  • 5
  • 34
  • 56
1800 INFORMATION
  • 131,367
  • 29
  • 160
  • 239
  • 1
    Re: Visual Studio saving files in all-lowercase Which version of Visual Studio are you using? Last I checked this seemed to be better in the 2008 version. In 2005 the bug seemed to occur when files were opened via the debugger instead of solution explorer. – Adam Mitz Sep 10 '08 at 06:43
  • Actually yes this is 2005. No chance of an upgrade for a while though. – 1800 INFORMATION Sep 10 '08 at 19:53

7 Answers7

232

Since version 1.5.6 there is an ignorecase option available in the [core] section of .git/config

e.g. add ignorecase = true

To change it for just one repo, from that folder run:

git config core.ignorecase true

To change it globally: 

git config --global core.ignorecase true
Brendan Nee
  • 5,087
  • 2
  • 33
  • 32
MarkB
  • 5,117
  • 3
  • 22
  • 8
  • 23
    git config core.ignorecase true or git config --global core.ignorecase true to apply globally. – Aaron Jensen Oct 10 '08 at 22:33
  • @graywh: It's documented in git-config under core.ignorecase (http://www.kernel.org/pub/software/scm/git/docs/git-config.html) – Ben Lings Jul 19 '10 at 13:06
  • 6
    Thanks, I finally found why git was not taking my case changes into account. `ignorecase = false` did the trick, it was defaulted to `true` -_- – Alex C Mar 31 '16 at 14:36
  • 1
    [Git Documentation](https://git-scm.com/docs/git-config/#Documentation/git-config.txt-coreignoreCase) says: `core.ignoreCase` Internal variable which enables various workarounds to enable Git to work better on filesystems that are not case sensitive, like APFS, HFS+, FAT, NTFS, etc. 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 repo is created. – Danijel Jan 26 '21 at 08:59
  • Note that `core.ignorecase` may not be respected for all git commands. I've seen `git show` and `git ls-files` fail because of casing even though `core.ignorecase` was set to true – derekantrican Oct 25 '21 at 23:03
  • You can set `core.ignorecase` (or `core.ignoreCase`) globally, but it will have no effect because *every Git repository* has a *local* `core.ignorecase` setting, which Git set when Git created the repository, after testing out the OS's file system's behavior to see if the file system ignores case. – torek Oct 24 '22 at 19:24
20

You can force git to rename the file in a case-only way with this command:

git mv --cached name.txt NAME.TXT

Note this doesn't change the case of the file in your checked out copy on a Windows partition, but git records the casing change and you can commit that change. Future checkouts will use the new casing.

Andrew Arnott
  • 80,040
  • 26
  • 132
  • 171
  • 13
    "error: unknown option `cached'." It's not listed in the docs, either: https://git-scm.com/docs/git-mv – Alex Jun 20 '20 at 09:20
15

In git version 1.6.1.9 for windows I found that "ignorecase=true' in config was already set by default.

John C
  • 303
  • 1
  • 3
  • 8
  • 10
    Yes, and when you work with Java files, you want this setting to be set to false, otherwise you might be in trouble when doing such refactoring (class HTMLParser becoming HtmlParser or the reverse). – PhiLho Nov 30 '12 at 14:38
  • same for git version 2.10.1.windows.1 – Kars Barendrecht Dec 28 '16 at 13:22
  • 4
    I know this is old, but it's nonsensical on windows to set ignorecase to false as Windows is a case-insensitive operating system. This applies whether you're working with Java or (gasp!) C# or anything else. – ingyhere Apr 25 '18 at 17:50
  • 4
    It's not nonsensical at all, because we're programmers that need files to be named a certain way. For instance for C#/Unity it matters to find the class contained in the file. Renaming that file on one machine and checking it in breaks the build on other machines in a non-transparent way. I'm adding ignoreCase=false to the mandatory co-worker git settings! – Luc Bloom Jul 12 '21 at 09:26
5

To force git to recognize the change of casing to a file, you can run this command.

  1. Change the File casing however you like
  2. git mv -f mynewapp.sln MyNewApp.sln

The previous command seems to be deprecated now.

FoxDeploy
  • 12,569
  • 2
  • 33
  • 48
5

The situation described in the question is now re-occuring with Mac OS X, git version >= 1.7.4 (I think). The cure is to set your ignorecase=false and rename the lowercased files (that git changed that way, not Visual Studio) back to their UsualCase by hand (i.e. 'mv myname MyName').

More info here.

akauppi
  • 17,018
  • 15
  • 95
  • 120
1
  1. From the console: git config core.ignorecase true
  2. Change file name capitalisation
  3. Commit
  4. From the console: git config core.ignorecase false

Step 4 fixed problems checking out branches with a different capitalisation.

Mario
  • 31
  • 1
  • 1
0

Possible finding (As of VS 2019 16.11.26): If the path to the project file in the SLN file is a different case from everywhere else this might also trigger the condition. We found this by right click on the Project in the solution and choose Open Folder in File Explorer. We noticed the path at top of file explorer was the case in the SLN file and not what was in the file system if you just opened this path on your own via File Explorer. So we suspect this path in the SLN was being passed to some git operations and the other version of the path was passed at other git operation times. Or the git operations have not received the core.ignorecase love.

DaveWilliamson
  • 370
  • 1
  • 11