Why does tracking branch create a new remote branch?
I had a git repository with a remote branch origin/master.
I needed the repository to track a branch on another remote git server m1/master. So I added the new remote server using the
git remote add command.
So I performed the following command:
$ git branch -a * master remotes/m1/master remotes/origin/master
So checking out the m1 master branch
$ git checkout -b m1-master m1/master Branch mht-m1 set up to track remote branch master from m1. Switched to a new branch 'm1-master'
Now doing a
$ git push Total 0 (delta 0), reused 0 (delta 0) To git@<m1 server>/repo.git * [new branch] m1-master -> m1-master
git push on the tracking branch
m1-master create a new remote branch, instead of pushing changes to the existing remote branch that it tracks? What am I missing here?
PS: Using git version 220.127.116.11
2 Solutions collect form web for “Why does tracking branch create a new remote branch?”
OK, first, some terminology:
A (regular, ordinary, local) branch is something like
A “remote branch” like
origin/masteris something stored in your local repository, to remember where, on the remote, the remote had its own (local) branch pointing.
A “remote branch” gets updated when you contact the remote (typically on fetch and push). At that time, your local git finds out what branches they have, and updates these.
A “tracking branch” is a local branch that records two items: a “remote”, typically a name like
origin, and another “merge” name. For instance, if your local branch
masteris a tracking branch, it may be configured with
branch.master.remote = originand
branch.master.merge = master. Annoyingly, you can’t always just string these together (you have to map through
remote.origin.fetchto be completely correct with this) but in general this means that your local
You can’t1 create a “remote branch” locally. You have to
push to/from the remote. If that remote has a local branch named
X, your git then records the remote’s idea of that branch, using the
origin/X style name.
So, what’s going on here? Well, you did this:
$ git checkout -b m1-master m1/master
That creates a local branch named
m1-master. (This local branch is also a tracking branch, but that’s only partly relevant here, because of the
push.default setting below.)
Then, you did this:
$ git push
(with no remote name and no refspecs after
push). Git uses the default remote, which turns out to be
m1 because of the tracking. Next though, git uses a default refspec, based on
push.default and/or other
git config items.
As of git 18.104.22.168 the “default
matching. This would not create a new branch (but also won’t push anything unless there’s an
m1-master there). You have it set to
current, which means: “please update or create, on the remote, the current branch, using its current name.” The current branch is
m1-master, so that was created.
upstream to fix this:
git config push.default upstream
(Also, see “Warning: push.default is unset; its implicit value is changing in Git 2.0” for various other options.)
1Well, you can do it with
git update-ref or manual poking about in your
.git directory. 🙂 Just, not with “normal” user commands.
Because of the
push.default configuration option Git obeys. To cite the
git-config(1) manual page:
Defines the action git push should take if no refspec is given on the command line,
no refspec is configured in the remote, and no refspec is implied by any of the
optionsgiven on the command line. Possible values are:
nothing – do not push anything.
matching – push all branches having the same name in both ends. This is for those
who prepare all the branches into a publishable shape and then push them out with a
single command. It is not appropriate for pushing into a repository shared by multiple
users, since locally stalled branches will attempt a non-fast forward push if other
users updated the branch.
This is currently the default, but Git 2.0 will change the default to simple.
upstream – push the current branch to its upstream branch. With this, git push will update the same remote ref as the one which is merged by git pull, making push and pull symmetrical. See “branch.<name>.merge” for how to configure the upstream
simple – like upstream, but refuses to push if the upstream branch’s name is different
from the local one.
This is the safest option and is well-suited for beginners. It will become the default in Git 2.0.
current – push the current branch to a branch of the same name.
The simple, current and upstream modes are for those who want to push out a single
branch after finishing work, even when the other branches are not yet ready to be pushed
out. If you are working with other people to push into the same shared repository, you
would want to use one of these.
So I’d say for some reason you have
push.default set to
upstream and so mere running
git push sends to the default remote your currently checked out branch trying to update there a ref with the same name (possibly creating it).
You could verify if this is true by running
git config --get-all push.default
in your repository.