Running
git config push.default upstream
will give you the desired behavior.
According to the git config
documentation, the default behavior in version 2.0 is
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.
When pushing to a remote that is different from the remote you normally pull from, work as current. This is the safest option and is suited for beginners.
In contrast, the upstream
mode operates as follows.
upstream
- push the current branch back to the branch whose changes are usually integrated into the current branch (which is called @{upstream}
). This mode only makes sense if you are pushing to the same repository you would normally pull from (i.e., central workflow).
Working with a repository similar to yours
$ git branch
* cloud
master
and nothing up my sleeve
$ git config --unset push.default
attempting to push gives the same error. Verbose mode (-v
) is there so you can see what git is doing.
$ git push -v
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 amazon HEAD:master
To push to the branch of the same name on the remote, use
git push amazon cloud
To choose either option permanently, see push.default in 'git help config'.
After a config change
$ git config push.default upstream
you get the behavior described in your question.
$ git push -v
Pushing to .../amazon/
To .../amazon/
= [up to date] cloud -> master
updating local tracking ref 'refs/remotes/amazon/master'
Everything up-to-date