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?
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.