11

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?

manojlds
  • 290,304
  • 63
  • 469
  • 417
franmon
  • 2,057
  • 2
  • 19
  • 25
  • @meagar is right; you'll want to mandate a consistent casing for branch names, and generally avoid having things that are named the same except for case. But as a note, the windows registry setting HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive apparently allows git to work the way it wants to (I *am* using git through cygwin; unsure if msysgit behaves the same way). – Sumudu Fernando May 04 '13 at 05:57

2 Answers2

20

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.

manojlds
  • 290,304
  • 63
  • 469
  • 417
  • Thank you very much for the explanation. I am still new to Git, so I did not know that branches ended up being simple metadada files. I already knew the difference in case sensitivity between Linux and Windows, but it was difficult for me to understand the difference in the treatment of case between code files and branches on Linux. Now I understand. – franmon Dec 09 '11 at 13:44
8

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.

user229044
  • 232,980
  • 40
  • 330
  • 338
  • The expression that Windows and Mac OS X are fundamentally "broken case-insensitive operating systems" is unhelpful. While equally unhelpful, it is more reasonable to argue that git is poorly designed by storing branch names as file names directly on the file system without cognizance of the file system's capabilities. – ctpenrose Apr 16 '14 at 18:10
  • If Git was required to normalize on the quirky behaviour of every operating system, it would never have been finished. Answer stands. – user229044 Apr 16 '14 at 18:31
  • Based on your description, it sounds like the property should have been named something like "core.forcecase". Like the OP, I would also have expected a flag named "ignorecase" to make the system ignore case (case-insensitive). – thelr Aug 12 '14 at 15:37