How to make "git branch" respect the "core.ignorecase" flag on Linux?

Question

We are using a remote Git repository located on a Linux server at the office. All clients are Windows PCs with Git Extensions installed as a client (running with msysgit).

On a client system, if I try to do the following:

git branch Branch1
git branch branch1

the second command is going to fail, telling me that a branch with that name already exists. That is what I expect, since I set the core.ignorecase to true in git config.

But, if I log onto the Linux system directly and run the same commands, both branches will get created, even if the core.ignorecase flag is set to true.

I would have expected the second command to fail too, since I configured the repository to ignore the case, but either the flag does nothing on Linux systems, or I missed something.

Can anyone help me understand the issue as we plan on migrating our SCM from Source Safe to Git shortly and this issue is scaring us. What would happen if two developers create branches with the same name, but different case, and push the result on the Linux repository?

Answer 1

I would like to add more details over @meagar's answer:

FAT32 / NTFS are case-preserving file systems. That is, if you name a file "Foo.txt", it will be stored as ""Foo.txt". If you save a file as "foo.txt", it will be saved as "foo.txt". But since it is case-insensitive, "Foo.txt" and "foo.txt" are effectively the same and you cannot have both files in the same directory.

In your repository in Windows, if you change the name from "Foo.txt" to "foo.txt", and if you do not git to show that as a change , you can set core.ignorecase configuration to true and git will not see that as a change. If you set it to false it will. ( But because of the nature of the filesystem and git, it will seem like a new file foo.txt was added, adding to confusion on Windows).

That's the purpose of the core.ignorecase

Coming to the branch. Branches are just pointers to a commit. These pointers are just files. These files are stored in .git/refs/heads. When you create a branch, say, bar, a file named .git/refs/head/bar is created. Now, in Linux, when you create a branch named Bar, it can go ahead and create a file .git/refs/head/Bar and hence allows the branch creation. But on Windows, you cannot create .git/refs/head/Bar and hence you will not be able to create the Bar branch when bar exists. Realize that core.ignorecase is to do with files in your repository - your code base - and has no influence over the metadata files of git.

So you will have to live with and adjust to the fact that in Linux, you can create branches with same names, differing in case, but in Windows, you cannot.

Answer 2

How to make “git branch” respect the “core.ignorecase” flag on Linux?

You can't, because the flag doesn't do what you think it does.

core.ignorecase

If true, this option enables various workarounds to enable git to work better on filesystems that are not case sensitive, like FAT.

core.ignorecase has nothing to do with the behaviour you're describing, it is unrelated to the case-sensitivity of branch names. Git being unable to tell the difference between Branch1 and branch1 on Windows isn't related to whether core.ignorecase is set, it would behave the same way regardless.

... but either the flag does nothing on Linux systems, or I missed something.

You didn't miss anything. The flag does nothing on Linux systems. core.ignorecase isn't for making operating systems case-insensitive, it's for allowing Git to work on broken case-insensitive operating systems. Linux is fundamentally case-sensitive, and so is Git. You should be trying to work with this, and mandating that your developers use lower-case for their branch names. You should not be trying to make Git emulate broken behaviour from other operating systems.

What would happen if two developers create branches with the same name, but different case, and push the result on the Linux repository?

Then you would have two completely different branches, one in lower-case and one which was wrongly named, and somebody would be forced to merge and discard their wrong branch. This is something you'll be doing routinely anyways, as a side-effect of using Git.