84

After doing a checkout of the remote branch releases/rel_5.4.1 using the Git GUI, I'm seeing this unexpected error message when I try to push:

fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:releases/rel_5.4.1

To push to the branch of the same name on the remote, use

    git push origin rel_5.4.1

I don't know what Git is talking about. I probably want to push to origin releases/rel_5.4.1 since that's the branch which I checked out. So neither option seems correct to me.

git status says I'm on branch rel_5.4.1.

Here is the branch as it appears in my .git/config:

[branch "rel_5.4.1"]
    remote = origin
    merge = refs/heads/releases/rel_5.4.1

What is going on?

Aaron Digulla
  • 297,790
  • 101
  • 558
  • 777

5 Answers5

88

ATTENTION! While this answer has the most votes and is technically correct, it suggests that the problem is the push.default option, when usually the real problem is an unintended mismatch between the names of the local branch and the upstream branch. blindly following the instructions in this answer may cause your changes to be pushed to the wrong branch! For a safe quick fix, please see https://stackoverflow.com/a/24865780/2279059 instead.

For the benefit of the readers who might miss the probably most important detail, well hidden in the comments:

This is due to the git config push.default setting. It defines what git does when you enter git push (see link).

In the question, apparently the setting was set to simple (which is the default for git v2), probably with

git config --global push.default simple

This means, that git refuses to push when the local and remote branch do not match exactly.

As @TomSpurling notes, above setting is safer and recommended for normal use, because usually you want the same names for your local and remote branches.

However in certain situations, when your local branch is tracking some different remote branch with a different name, then you want to change that:

To allow to push to the tracking branch on a per-git basis, thus make git pull and git push symmetric, use

git config push.default upstream

Note: To globally set this for all of your gits, use git config --global push.default upstream
However it is probably better to leave it to git config --global push.default simple and only set this option in those workloads, where it is really required.

Florian Winter
  • 3,381
  • 1
  • 33
  • 52
Tino
  • 7,380
  • 3
  • 48
  • 52
  • 1
    The comments I reference are thos from @Tom-Spurling and Jacob-Ford – Tino Mar 07 '17 at 07:33
  • 1
    I believe that should be the best answer! because i don't want to mention the tracking branch everytime i push. – basslo Oct 27 '17 at 12:01
  • 4
    This is definitely relevant as a footnote, but this particular question seemed to be mostly about ending up with a non-matching branch name by mistake... so this might not be a better answer _for this question_, even if we're all really likely to end up here by searching for that error message when deliberately having a different branch name. I suppose an ideal answer would mention both points! (?) – Tom Spurling Apr 24 '18 at 19:11
  • 1
    @TomSpurling edited accordingly, so recommendation is to only to set this `--local` now. – Tino Aug 07 '19 at 14:46
  • 3
    This was absolutely the correct answer for me. i intentionally name branches differently on checkout to organize them my own way, and having to constantly instruct git that i created the upstream link to a different branch name ON PURPOSE is irritating. This fixes it. THANKS! – cautionbug Sep 17 '20 at 21:51
65

This happens if the name of the upstream branch and local branch do not match, which sometimes happens, and usually is unwanted:

> git status
On branch release-1.2.3
Your branch is up to date with 'origin/master'.

To solve this, run:

git branch --unset-upstream

Then, once you run git push again, you will be asked to use the --set-upstream option to set the upstream branch correctly.

Florian Winter
  • 3,381
  • 1
  • 33
  • 52
gpap
  • 818
  • 6
  • 7
  • 7
    this is more true in the case you run into when you rename a branch, via `git branch -m newbranch`, that had an upstream set, and attempt to git push. in that case `git branch --unset-upstream` and then do `git push` and git will tell you `fatal: The current branch newbranch has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin newbranch` – harschware Jan 22 '18 at 21:27
48

Your local branch is called rel_5.4.1 but the remote branch is releases/rel_5.4.1 (as far as Git is concerned, the / has no special meaning in branch names except to make them easier to read for the human eye).

When you push, Git is wary whether you want to push your branch to releases/rel_5.4.1 (the name of the remote branch) or whether you want to create a new remote branch. It does notice the similarity of names, though.

Unless you want to create a new branch, the correct command is

git push origin HEAD:releases/rel_5.4.1

You could also use

git push origin rel_5.4.1:releases/rel_5.4.1

To fix the warning once and for all, rename your local branch to match the remote name:

git branch -m releases/rel_5.4.1
Aaron Digulla
  • 297,790
  • 101
  • 558
  • 777
  • 5
    Good answer, especially the final conclusion. IMO reasons for using different names locally and remotely are rare unless you are working with two or more different upstreams having the same branch name. But in this situation, typing the push target manually on the command makes me feel more *safe* than using some automagic solution – hek2mgl Jul 21 '14 at 13:41
  • 4
    I agree with the conclusion that it is generally sanest and least confusing to keep the branch names the same both sides. Git also agrees, which is why the default value for **push.default** in config is **simple**, which enforces this sanity. From the man page: "**simple** - in centralized workflow, work like **upstream** with an added safety to refuse to push if the upstream branch's name is different from the local one." If you want the same basic behaviour (push only my current branch by default) without that check, change the config for your repo: `git config push.default upstream` – Tom Spurling Feb 04 '16 at 15:40
  • 7
    If I checkout the branch using `git checkout -b branchname --track origin/releases/branchname` I've taken the trouble to tell Git the name of the upstream branch and requested that it track it. No magic matching required, no danger, I said what I want for this branch - and yet still it raises this error. Why does the tracking apply to 'pull' but not 'push'? – Ed Randall Oct 17 '16 at 15:26
  • > *as far as Git is concerned, the / has no special meaning in branch names except to make them easier to read for the human eye.* Not true, try: `git branch test-bname; git branch test-bname/with-slash` – qonf Feb 15 '17 at 14:07
  • I must be missing something here. If the local and remote branch have the same name, how can I tell them apart when looking at the commit tree? For example `git log --graph --full-history --all --color --pretty=format:"%x1b[31m%h%x09%x1b[32m%d%x1b[0m%x20%s"` – Dave B Jan 05 '18 at 17:30
  • 2
    @DaveB Try `git log --graph --color --oneline --decorate --all` instead. At my side tags become yellow, local branches green and remote branches red. Remote branches can also be detected on their name, as they are always prefixed with the remote's name, which usually is `origin` after `git clone`. So the remote's `master` branch is locally referred to as `origin/master`. (Note that nothing prevents you to `git branch origin/master`. Just don't do things like this!) Also, to sync your local "cache" with all current remote branch names, `git remote update -p` is your friend. – Tino Aug 07 '19 at 15:01
36

This error can be fixed for once and all, with:

git branch releases/rel_5.4.1 -u origin/releases/rel_5.4.1

It changes the upstream of the branch, to match the correct remote (again).

s.meijer
  • 1,968
  • 1
  • 21
  • 22
  • 12
    By default, `git config push.default` is set to `simple`, meaning it will never be happy if the remote branch doesn't match the local branch's name, even if the remote is set as the upstream. Setting `git config push.default upstream` will suppress those errors. – Jacob Ford Jul 20 '16 at 18:17
  • 1
    @JacobFord's comment is very important to note. As far as I know, this is the only way to deal with this without having to rename your local branch. – prasanthv Aug 23 '16 at 20:05
  • Thanks! That is exactly what I needed, though I am really confused why `git remote set-branch origin releases/rel_5.4.1` doesn't solve the problem ... – patapouf_ai Oct 21 '16 at 14:03
  • It's just because the default push behaviour ("`simple`") tries to be extremely "safe" -- so it only pushes a single branch, and only if the upstream branch name is identical (because you might have set a different upstream by accident! (I guess)). Changing it to "`upstream`" as I and @JacobFord mentioned is equivalent (pushes just the single current branch) without this extra "safety" (checking the names match). You can see all the options in the `push.default` section of the manual (`man git-config`). – Tom Spurling Apr 24 '18 at 19:16
  • 2
    That's the one I was looking for. In my case, I had renamed the branch local and remote, but git was still trying to use the old tracking branch. This fixed that and now a simple `git push` works again, even with the config set to `simple`. – fbicknel Jun 23 '19 at 17:58
  • This is THE answer for my case since I was unable to do a `git push` with `error: failed to push some refs to xxx`, and a `git pull` won't do anything but after applying this answer I was able to use `git pull` to merge the upstream with my local changes now. Solved my problem and huge thanks! – imgg Jan 15 '21 at 23:48
3

Seems like having a local branch name which is different than the remote is not what Git likes too much. You will need to issue:

git push origin HEAD:releases/rel_5.4.1

explicitely on every push

hek2mgl
  • 133,888
  • 21
  • 210
  • 235
  • Isn't `releases/` part of the branch name? – Aaron Digulla Jul 21 '14 at 12:10
  • Oh, yes. I overlooked that. It should start with `releases/`. Seems that the Git error message is misleading. (Now I got the question) – hek2mgl Jul 21 '14 at 12:11
  • Thanks. The previous command created a branch `rel_5.4.1` in my remote repo. I deleted it with `git branch -D rel_5.4.1`. Is that correct? – Aaron Digulla Jul 21 '14 at 12:12
  • :-( `error: src refspec releases/rel_5.4.1 does not match any.` What's it doing now? – Aaron Digulla Jul 21 '14 at 12:13
  • 1
    Yes, this is the first step it deletes the branch locally. The next step would be `git push --delete origin rel_5.4.1` which would delete the branch remotely.. – hek2mgl Jul 21 '14 at 12:15
  • I need to setup some test repo to reproduce. I never used branch names having a path component... – hek2mgl Jul 21 '14 at 12:16
  • It seems git gets confused because of the missing `releases/` prefix of my local branch. That is something I could understand if it had complained at the time when I checked this branch out ... – Aaron Digulla Jul 21 '14 at 12:19
  • What is the value of `git config push.default`? Are you using a git version >= 2? – hek2mgl Jul 21 '14 at 12:21
  • `push.default=simple` and Git version is 1.9.1. – Aaron Digulla Jul 21 '14 at 12:22
  • This seems to be the fix for my problem: `git branch -m releases/rel_5.4.1` – Aaron Digulla Jul 21 '14 at 12:24
  • Hmm, I used 1. `git config push.default simple` 2. `git checkout -b releases/test` 3. `commit something ` 4. `git push`... I got the error message: http://pastebin.com/YE6jGpUw .. (Which looks ok in that case) I'm also using git 1.9.1. Can you reproduce that with a *hello world* repo? – hek2mgl Jul 21 '14 at 12:30
  • Try to checkout `releases/test` as `test`. Note that my local branch is missing the prefix. – Aaron Digulla Jul 21 '14 at 12:38
  • Oh, I thought the misssing prefix was an error in your git config. – hek2mgl Jul 21 '14 at 12:39
  • (Now can reproduce it :) – hek2mgl Jul 21 '14 at 12:42
  • Seems like having a different local branch name than remote is not what git likes. You will need to issue `git push origin HEAD:releases/test` explicitely on every push (this will be my final answer, srry it took me some time to reproduce that) – hek2mgl Jul 21 '14 at 12:46
  • You will not, in fact, "need to" do this. – Leif Willerts Mar 09 '21 at 15:09