0

The tl;dr of the question is in the title, but here's the scenario:

I have project P forked on github, which has been sitting stale for sometime. Meanwhile, the upstream version of the project has been moving forward, with some commits and, critically, some new branches.

So, now I want to dust it off and get up to date. I clone the existing fork of P into my machine, and check git status: 

On branch master
Your branch is up-to-date with 'origin/master'.

So, the local master is tracking origin/master. Now, I add the upstream remote and do a git fetch upstream, where I see that there are some new branches. I want to get some of those into origin too, and that's where I'm confused. After a lot of searching, it seems that the common advice is similar to the one here: Get new upstream branch with git where you set up new local branches to track the new upstream branches, and then push them into your origin.

The issue is, after this process, your master is set to track origin/master, and shinynewbranch is set to track upstream/shinynewbranch, and the asymmetry of this tells me something is wrong.

So, what is the common convention regarding tracking, when there's both an origin and an upstream involved? Is "master tracks origin, other branches track upstream" truly the common pattern?

Community
  • 1
  • 1
Sundar R
  • 13,776
  • 6
  • 49
  • 76

2 Answers2

1

This is a bit of a qualitative question. There's no "right answer" - it's up to you to determine which of your two equally-valid remotes a given branch will track.

You can push anything anywhere. There doesn't have to be a named branch to push something: you can do, for example, git push origin upstream/foo:refs/heads/foo to push upstream's foo branch to origin without there ever having been a local branch at all.

Borealid
  • 95,191
  • 9
  • 106
  • 122
  • Thanks. I wish I could set `origin` branches tracked for `push`es and `upstream` branches for `pull`s, making both operations convenient. And `git status` being able to tell me both `master is N commits ahead of origin/master` as well as `master is X commits behind upstream/master` would be great - but since I _have_ to choose only one of them, I think I'll go with having `master` and every other branch track `upstream` itself. – Sundar R Aug 18 '15 at 22:21
  • You can set different repositories for pushes and pulls if you wish. Read the help for ‛git config‛ – Borealid Aug 18 '15 at 22:23
  • Wow, git is full of pleasant surprises like this. `branch..pushremote` and `remote.pushdefault`. Thanks again. – Sundar R Aug 18 '15 at 22:32
1

The upstream remote is most commonly used to keep your fork synced with the original repository, as you described. Since you are pushing changes to your fork and not to upstream directly it makes sense to track origin/master. Once you want to push your changes to upstream you make a pull request.

kraeki
  • 51
  • 1
  • 2