Select Page

Introduction

Whether or not you like it, git is case-sensitive. This gives rise to a lot of flexibility over the the names you could give to your branches in a repository, but at the same time, it raises concerns, such that lead many to see the following error message:

“………… Cannot be resolved to branch”

with whatever other text there might initially be. There are also other cases that might not be due to this case-sensitivity. So in this article, we’ll break down the fundamentals that causes you to see this error message, and how to fix it right at the instance you face it. 


‘Cannot be resolved to branch’ example scenario

Let’s take a very basic example in account to better understand what the case actually is. First up, I’d create a folder and initialize it with git, as usual:

$ mkdir test
$ cd test
$ git init

Now let’s create a demo file and commit it for the sake of fulfillment:

$ touch demo.txt
$ git add demo.txt
$ git commit -m “demo.txt created”

Alright! So far so good! How about we create a separate branch to work on a special feature for our demo.txt file? (Doesn’t make sense, but just accept it for now!):

$ git checkout -b Feature/Newline

Very well indeed. Let’s just assume that I did a whole lot of work here, and I’m done with this part of the feature for now. So I’d now go back to the master branch:

$ git checkout master

Hmmmm… I guess I need another small feature to be added before I call it a day. Alright. Let’s create another branch, but this time the feature directory will start with a lowercase f so that it can be distinguished as a separate set of features:

$ git checkout -b feature/tabs

After a long session of some good work, I’m now ready to push to the remote origin (whatever it may be set to). To do this, I use the following command:

$ git push origin Feature/Newline
$ git push feature/tabs

Boom! The second line of command throws an error:

$ fatal: feature/tabs cannot be resolved to branch

Arrgghhh! How annoying is that! What am I doing wrong? Isn’t everything supposed to be working just fine? 

Not really.


How to fix ‘Cannot be resolved to branch’ in git

Changing the case of branch name

Despite how weird it might sound and seem, that is the truth, and how git works. Git has become so feature-rich to the point, when it has a hard time handling simpler issues and cases like this. You’ll understand what I’m talking about in a minute.

If you now try to use the git branch command to look out for the names of your branch you had applied, look what you’d get:

$ git branch -a
     Feature/Newline
*    Feature/tabs
     master

Could you catch the problem here yet?

What’s going wrong?

If you notice properly, you should see that the casing of the branch name changed automatically, that is, I had named the branch “feature/tabs” and it got changed to “Feature/tabs”. What this also means is that both the tabs file and the Newline file are actually stored under the tree reference, which is not what we intended. As it appears to be, git renames the branch automatically sometimes, with its purpose unclear. It’s hard to tell whether it is a bug or not, or if git is actually trying to fix typos by thinking that I intended both tabs and Newline files to be under Feature, instead of storing them separately. 

To further clarify my statements, let me show you by creating two more branches, and naming them document with the different casing on each. This time around, I’ll name the first one with lowercase, and the second one with uppercase to check whether git is actually renaming it on purpose:

$ git checkout -b document/file1
$ git checkout -b Document/file2

Now once again, if I try the git branch command, look what I get back in output:

$ git branch -a      
     Feature/Newline
     Feature/tabs
     document/file1
*    document/file2
     master

Just as I had expected – the second branch that I named “Document/file2” actually got changed to “document/file2”. Git appears to have renamed it on purpose. When it saw that there was already a branch root called document, now creating a new branch with a similar set of characters, despite the casing, will automatically be renamed by git to match them up. At this point, if I try pushing code to what I set the branch name initially:

$ git push origin Document/file2


It wouldn’t work and will return the same “could not resolve” error, as git has already renamed it by now. But what’s very annoying here, is that when you use the checkout command, git will still show you the very name you gave to the branch yourself, and silently rename it behind the woods. What I mean is this:

$ git checkout -b Document/file2

Git will return me an output like this:

Switched to a new branch ‘Document/file2’

Notice the casing there. Despite what it had outputted, it will still rename the branch and will not even inform you. This is very likely to be a cause why many fail to figure out why they are unable to push code to their branches. 

What to actually do to fix it

There’s nothing much that you could really do to fix this. The moral here is that if you see the error message, you should first use the git branch command to check what git had renamed the branches to. Afterwards, you can either use that name to given by git when using git checkout or git push the next time, or if you actually intended them to be separate branch roots, you should name them with different letters, so as to prevent git from renaming them.