2

If I do a git push, I see 3 branches involved. 1) The local branch I am working on, say 'foo1' 2) the local remote-tracking branch 'origin/foo2' (which always is on the same commit as the remote foo3 after push/pull) 3) 'foo3' in the remote repo. Naturally normally they all would be called foo, but I want different names so I can properly understand git and ask this question here. I don't understand where I can specify foo2. When I do

git push origin foo1:foo3

And having that in my .git/config

[branch "master"]
remote = origin
merge = refs/remotes/origin/foo2

Point 1 and 3 are ok, but I don't have an origin/foo2 in my local repo. What am I missing? Or is the answer that my remote tracking branches are always named exactly the same way as the remotes - that would be fine for me - I just want to understand git properly.

The git-push manual also only talks about two refs (the refspec src and dst), point 1 and 3, in my example. Where does the manual talk about that after the dst branch on the remote repo is updated, also the local remote-tracking ref is updated?

Florian Kaufmann
  • 803
  • 6
  • 13
  • @VonC's answer is correct (of course :-) ). I suspect the fundamental problem here is that you're tripping up over the apparent symmetry between `push` and `pull`. It's a false symmetry. The opposite of `push` is not `pull`, it's `fetch`. (Even then they're not precisely symmetric.) Keep that in mind and everything should make more sense. – torek Apr 08 '12 at 21:25

2 Answers2

1

You don't see three branches on git push. Only two

The foo2 you are describing is for git pull (git fetch + git merge) or git rebase:
(from git config)

branch.<name>.merge

Defines, together with branch.<name>.remote, the upstream branch for the given branch.
It tells git fetch/git pull/git rebase which branch to merge and can also affect git push (see push.default).
When in branch <name>, it tells git fetch the default refspec to be marked for merging in FETCH_HEAD. The value is handled like the remote part of a refspec, and must match a ref which is fetched from the remote given by "branch.<name>.remote".

The merge information is used by git pull (which at first calls git fetch) to lookup the default branch for merging.
Without this option, git pull defaults to merge the first refspec fetched.
Specify multiple values to get an octopus merge.

Note that with after git1.7.10, the default push policy might change to matching to upstream (see "What is the result of git push origin?"), which means, branch.<name>.merge defining an upstream branch (in the absence of branch.<name>.remote), it could then be used by default for a git push.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

You're right, the remote-tracking branch has the same name as the branch on the remote repo. It would be somewhat confusing otherwise !

So, origin/foo3 simply represents branch foo3 in the remote origin. It will be properly synced with the remote after running git fetch. Note that when running git pull, you are actually running git fetch ; git merge.

When running git push origin foo1:foo3, you push your local branch foo1 to the remote branch origin/foo3. So in your case it doesn't make sense to specify a branch foo2.

François
  • 7,988
  • 2
  • 21
  • 17
  • See, I can do `git checkout -b foo1; git pull origin foo3:remotes/origin/foo2`. So in the pull scenario I have now exactly the 3 branches described in my question. Here it is possibly to specificity each of the 3 branches. All three _can_ have different names, even though it might make no sense. But somehow the other way round, can only affect foo1 and foo3 (`git push origin foo1:foo3`), but no longer foo2, and this totally confuses me; I don't understand that asymmetry. I am sure i miss something. – Florian Kaufmann Apr 08 '12 at 20:27