Git – Branch Name Case Sensitivity Explained

gitgit-branchgithubversion-control

I am a new git user and recently been handed with an out of date git repository to look after.

This is the original state ( output by git show-branch):

! [cr232] CR 232 Release
        * [dev] Style Changes
---------------
        *   [dev] Style Changes
        *   [dev^] SMS 5.4
        *   [dev~2] Logo Change
        *   [dev~3] SMS 5.3
        *   [dev~4] SMS 5.2
        *   [dev~5] SIT R-0.3.3 EDW SMS Layers
        *   [dev~6] SIT Release R 0.3.0
       +*   [cr232] CR 232 Release
       +*   [cr232^] Dashboard Fix
       +*   [cr232~2] Release for system testing

Note that there is a branch called ‘dev’ at this point. Note that highlighted there are several references to dev (i.e. dev, dev^, dev~2 etc).

For my development purpose, I was trying to come up with a branch called ‘DEV’, all capital.

So I went ahead and create new branch (git branch DEV) and now running git show-branch –date-order:

! [DEV] Style Changes
    ! [cr232] CR 232 Release
        * [dev] Style Changes
---------------
        *   [DEV] Style Changes
        *   [DEV^] SMS 5.4
        *   [DEV~2] Logo Change
        *   [DEV~3] SMS 5.3
        *   [DEV~4] SMS 5.2
        *   [DEV~5] SIT R-0.3.3 EDW SMS Layers
        *   [DEV~6] SIT Release R 0.3.0
       +*   [cr232] CR 232 Release
       +*   [cr232^] Dashboard Fix
       +*   [cr232~2] Release for system testing

Note that both dev and DEV are listed as branch. Note also that on the 5th line the references to dev have now changed to DEV (i.e. DEV, DEV^, DEV~2 etc).

What is the 5th line output referring to? I would expect it to remain “dev” instead of being changed to “DEV” as the descriptions next to it refers to the description of old work during “dev” branch.

I am trying to return back to how it was by modifying the DEV branch name to DV (running git branch –m DEV DV) and showing the branch now look like:

! [DV] Style Changes
    ! [cr232] CR 232 Release
        * [dev] Style Changes
---------------
        *   [DV] Style Changes
        *   [DV^] SMS 5.4
        *   [DV~2] Logo Change
        *   [DV~3] SMS 5.3
        *   [DV~4] SMS 5.2
        *   [DV~5] SIT R-0.3.3 EDW SMS Layers
        *   [DV~6] SIT Release R 0.3.0
       +*   [cr232] CR 232 Release
       +*   [cr232^] Dashboard Fix
       +*   [cr232~2] Release for system testing

Note that the branch is now including DV and dev. Note also that the 5th line references to dev have now changed to DV (i.e. DV, DV^, DV~2 etc).

Is there any way to get back to how it was during original state in term of the DV references? Did the git got confused and renamed my historic information with a branch that is similar and only differs by capital case?

Please assist on how I can fix this. Thanks heaps

Best Answer

Answering just the question in the subject line, without addressing anything about git show-branch (like ElpieKay, I never actually use git show-branch; it seems mainly mis-informative):

Git branch names—and tag names, and all other reference names, as Git calls them—were originally intended to be case-sensitive.

This all works perfectly on Linux / Unix machines, where Git's code is case-sensitive to start with. When Git stores branch names in the file system as file names (which it only does sometimes), the file system is also case-sensitive.¹

It sometimes fails on Windows and some MacOS systems. Specifically, it fails when Git stores references in individual files, whose names are derived from the reference name, and those file names are case-insensitive (e.g., case-preserving, but fold case during name-matching; or even converting everything to uppercase-only, as in the really old FAT 8.3 format, but we can hope no modern file system does this).

As noted above, Git does not always store reference names as file names. In fact, on initial clone, all the names are in a single file called .git/packed-refs,² so at this point they are case sensitive. But they become "unpacked" over time,³ and then on some systems they become case-folding.

Because it sometimes fails on some systems, it's generally best to avoid using multiple reference names that differ only in case.

¹Of course, on modern Unix/Linux systems, you can now get access to case-preserving-but-case-insensitive file systems, and Windows and MacOS can now be told not to do case-folding for some file systems. (But if you change from the defaults, expect software that is intended for your box to fail, because it will. Things like Photoshop internally try to use files named foo and FOO and expect this to refer to the same file!)

²This packed-references file has been around for quite a while, but not forever, and very early versions of Git may not use it. Internally, Git is acquiring a new "pluggable reference name interface" and future versions of Git might use neither this file, nor individual per-reference files.

³In general, creating or updating a reference causes an unpacked reference file to come into existence. Running git pack-refs --all will replace unpacked references with packed ones, restoring full case-sensitivity. Without --all, git pack-refs only packs already-packed references, which is largely a useless mode of operation (it was intended for a case that is no longer used).

Related Solutions

Git – How to Rename Branch to Remove Capitalization

Use git push origin old_name:new_name to define how the branch will be called on the server. You probably have the remote branch name in your .git/config file which was not updated.

GitHub – Fix Branch Case-Sensitivity Issue

Git is schizophrenic about this.¹ Parts of Git are case-sensitive, so that branch HELLO and branch hello are different branches. Other parts of Git are, on Windows and MacOS anyway, case-insensitive, so that branch HELLO and branch hello are the same branch.

The result is confusion. The situation is best simply avoided entirely.

To correct the problem:

Set some additional, private and temporary, branch or tag name(s) that you won't find confusing, to remember any commit hash IDs you really care about, in your own local repository. Then run git pack-refs --all so that all your references are packed. This removes all the file names, putting all your references into the .git/packed-refs flat-file, where their names are case-sensitive. Your Git can now tell your Abc from your abc, if you have both.

Now that your repository is de-confused, delete any bad branch names. Your temporary names hold the values you want to remember. You can delete both abc and Abc if one or both might be messed up. Your remember-abc has the correct hash in it.
Go to the Linux server machine that has the branches that differ only in case from yours. (It's always a Linux machine; this problem never occurs on Windows or MacOS servers because they do the case-folding early enough that you never create the problem in the first place.) There, rename or delete the offending bad names.

The Linux machine has no issues with case—branches whose name differs only in case are always different—so there is no weirdness here. It may take a few steps, and a few git branch commands to list all the names, but eventually, you'll have nothing but clear and distinct names: there will be no branches named Abc and abc both.

If there are no such problems on the Linux server, step 2 is "do nothing".
Use git fetch --prune on your local system. You now no longer have any bad names as remote-tracking names, because in step 2, you made sure that the server—the system your local Git calls origin—has no bad names, and your local Git has made your local origin/* names match their branch names.
Now re-create any branch names you want locally, and/or rename the temporary names you made in step 1. For instance if you made remember-abc to remember abc, you can just run git branch -m remember-abc abc to move remember-abc to abc.

If abc should have origin/abc set as its upstream, do that now:
```
git branch --set-upstream-to=origin/abc abc
```
(You can do this in step 1 when you create remember-abc, but I think it makes more sense here so I put it in step 4.)

There are various shortcuts you can use, instead of the 4 steps above. I listed all four this way for clarity of purpose: it should be obvious to you what each step is intended to accomplish and, if you read the rest of this, why you are doing that step.

The reason the problem occurs is outlined in nowox's answer: Git sometimes store the branch name in a file name, and sometimes stores it as a string in a data file. Since Windows (and MacOS) tends to use file-name-conflation, the file-name variant retains its original case, but ignores attempts to create a second file of the other case-variant name, and then Git thinks that Abc and abc are otherwise the same. The data-in-a-file variant retains the case-distinction as well as the value-distinction and believes that Abc and abc are two different branches that identify two different commits.

When git rev-parse refs/heads/abc or git rev-parse refs/remotes/origin/abc gets its information from .git/packed-refs—a data file containing strings—it gets the "right" information. But when it gets its information from the file system, an attempt to open .git/refs/heads/abc or .git/refs/remotes/origin/abc actually opens .git/refs/heads/Abc (if that file exists right now) or the similarly-named remote-tracking variant (if that file exists), and Git gets the "wrong" information.

Setting core.ignorecase (to anything) does not help at all as this affects only the way that Git deals with case-folding in the work-tree. Files inside Git's internal databases are not affected in any way.

This whole problem would never come up if, e.g., Git used a real database to store its <reference-name, hash-ID> table. Using individual files works fine on Linux. It does not work fine on Windows and MacOS, not this way anyway. Using individual files could work there if Git didn't store them in files with readable names—for instance, instead of refs/heads/master, perhaps Git could use a file named refs/heads/6d6173746572, though that halves the available component-name length. (Exercise: how is 0x6d m, 0x61 a, and so on?)

¹Technically, this is the wrong word. It's sure descriptive though. A better word might be schizoid, as used in the title of one episode of The Prisoner, but it too has the wrong meaning. The root word here is really schism, meaning split and somewhat self-opposed, and that's what we're driving at here.

Best Answer

Related Solutions

Git – How to Rename Branch to Remove Capitalization

GitHub – Fix Branch Case-Sensitivity Issue

Related Question