CODEWITHSUNDEEP
gitversion-controlgithub
Nithin
Nithin

Reputation: 2283

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

$ git push
Total 0 (delta 0), reused 0 (delta 0)
To git@<m1 server>/repo.git
* [new branch]      m1-master -> m1-master

Why does 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 1.8.4.2

Upvotes: 1

Views: 1542

Answers (2)

torek
torek

Reputation: 487785

OK, first, some terminology:

  • A (regular, ordinary, local) branch is something like master.

  • A "remote branch" like origin/master is 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 master is a tracking branch, it may be configured with branch.master.remote = origin and branch.master.merge = master. Annoyingly, you can't always just string these together (you have to map through remote.origin.fetch to be completely correct with this) but in general this means that your local master is "tracking" origin/master".

You can't1 create a "remote branch" locally. You have to fetch or 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 1.8.4.2 the "default push.default" is 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.

Change push.default to 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.

Upvotes: 2

kostix
kostix

Reputation: 55443

Because of the push.default configuration option Git obeys. To cite the git-config(1) manual page:

push.default

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 current or 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.

Upvotes: 2

Related Questions