Can't push to remote branch, cannot be resolved to branch

Question

I migrated my repos from Bitbucket or Github. I don\'t think this matters but it\'s the only thing different... For a little while I had two remotes set up:

Answer 1

For my case, I used to have branch folder (or whatever it is called) with capital letters, then I create a new one with difference casing (lowercase) but git actually create the branch with capital.

I have created a branch like feature-ABC/branch1 before and pushed it. Then I create a branch feature-abc/branch2 (notice the lower-case ABC), and try to push it to remote using git push --set-upstream origin feature-abc/branch2 and get the 'cannot be resolved to branch' error. So I git branch and see that it actually created feature-ABC/branch2 instead of feature-abc/branch1 for me. I checkout again with git checkout feature-ABC/feature2 and push it using the uppercase (feature-ABC/feature2) to solve it.

Answer 2

Based on my own testing and the OP's comments, I think at some point they goofed on the casing of the branch name.

First, I believe the OP is on a case insensitive operating system like OS X or Windows. Then they did something like this...

$ git checkout -b SQLMigration/ReportFixes
Switched to a new branch 'SQLMigration/ReportFixes'

$ git push origin SqlMigration/ReportFixes
fatal: SqlMigration/ReportFixes cannot be resolved to branch.

Note the casing difference. Also note the error is very different from if you just typo the name.

$ git push origin SQLMigration/ReportFixme
error: src refspec SQLMigration/ReportFixme does not match any.
error: failed to push some refs to 'git@github.com:schwern/testing123.git'

Because Github uses the filesystem to store branch names, it tries to open .git/refs/heads/SqlMigration/ReportFixes. Because the filesystem is case insensitive it successfully opens .git/refs/heads/SqlMigration/ReportFixes but gets confused when it tries to compare the branch names case-sensitively and they don't match.

How they got into a state where the local branch is SQLMigration/ReportFixes and the remote branch is SqlMigration/ReportFixes I'm not sure. I don't believe Github messed with the remote branch name. Simplest explanation is someone else with push access changed the remote branch name. Otherwise, at some point they did something which managed to create the remote with the typo. If they check their shell history, perhaps with history | grep -i sqlmigration/reportfixes they might be able to find a command where they mistyped the casing.

Answer 3

I faced the same issue which was due to going to branch with wrong casing. git let me switch to branch with incorrect casing ie feature/Name instead of feature/name. Found an easier solution than listed above just:

• commit your changes to 'feature/Name'
• git checkout master (or develop)
• git checkout feature/name < with correct casing
• git push

Answer 4

For me, the issue was I had git and my macOS filesystem set to two different case sensitivities. My Mac was formatted APFS/Is Case-Sensitive: NO but I had flipped my git settings at some point trying to get over a weird issue with Xcode image asset naming so git config --global core.ignorecase false. By flipping it back aligned the settings and recreating the branch and pushing got me back on track.

git config --global core.ignorecase true

Credit: https://www.hanselman.com/blog/GitIsCasesensitiveAndYourFilesystemMayNotBeWeirdFolderMergingOnWindows.aspx

Answer 5

Slightly modified answer of @Ty Le:

no changes in files were required for me - I had a branch named 'Feature/...' and while pushing upstream I changed the title to 'feature/...' (the case of the first letter was changed to the lower one).

Answer 6

I ran into the same issue and noticed that I had mixed up the casing while checking out the branch. I checked out branchName instead of BranchName and when I tried to push to remote, I got the same error.

The fix:

git push --set-upstream origin BranchName

By setting upstream to the correct name, the correct branch was updated on github and I was then able to checkout the correct branch name with

git checkout BranchName 

And it should be up to date with your last push.