0

I just started with Git and Github and I am confused with the terms 'upstream' and 'downstream' when it comes to pushing.

I read this question here: Definition of "downstream" and "upstream" but the answer from brian d foy (most voted at time of writing this question) refers to cloning from a repo.

I am not cloning. I started with work in a directory and made it a repository with git init. I intend to work on it on my laptop and save my work on Github in case something happens to my laptop. My local repo will be the main repo.

Why does the command to push to Github have -u option in git push -u origin master which means upstream. Won't I be pushing downstream if the main repo is on my computer?

Community
  • 1
  • 1
heretoinfinity
  • 1,528
  • 3
  • 14
  • 33
  • 1
    And then how does that relationship change if your computer dies and you need to clone from github? (hint: it doesn't, these are just terms that are often convenient). – crashmstr Mar 24 '17 at 19:44
  • @crashmstr if it dies, then I would have to clone and then it would make sense that the Github repo is upstream since I am getting everything from there. – heretoinfinity Mar 24 '17 at 20:21

2 Answers2

2

The concept is not bound to the git clone <url> command itself (which is essentially not different from git init followed by git remote add origin <url>), but to the role each repo plays in your distributed version control. And this is not absolute when using a DVCS, as explained in the second answer of the question you've linked to.

I'd like to think the upstream is where the "official" or "common" version is, where anyone would ultimately consult to get the most truly version.

If others (or yourself in another computer) collaborate with you through Github, then Github will be primary holder of common information and the source for you and them to get the most recent updates. So it would be your upstream.

If, on the other hand, in case your local repo and Github's repo diverge somehow your version should be considered the most correct, then Github is your downstream, and you are effectively pushing information downstream. But for others, who get the information from Github, it is their direct upstream (and your repo an indirect upstream).

Edit:

About the -u|--set-upstream flag, it actually sets the remote tracking branch for the branch being pushed, because it is logical to track upstream (so you can receive fresh information), not downstream (that have the same or older information than you). As it is really uncommon to push/pull from downstreams, the flag has upstream in its name. Also, the concepts of upstream and downstream sometimes make less sense when you have a distributed architecture where that happens.

For the Github case, you can use the remote tracking information on the branch to simplify command usage, even though you consider it as your downstream.

Community
  • 1
  • 1
André Sassi
  • 1,076
  • 10
  • 15
  • And in general, you most people almost always pull from or push to upstream; you don’t care about your downstream as much. Your situation is not usual, in that you are pushing downstream as backup. Generally, I’d recommend using a different backup solution, but in certain cases this can work fine. – Daniel H Mar 25 '17 at 00:02
  • @DanielH could you name those backup solutions you were referring to? – heretoinfinity Mar 25 '17 at 01:53
  • @André Sassi in your last paragraph - there isn't a -d option though, is there to push downstream to work with this scenario - there's just a -u option so I have to think of Github as my upstream? – heretoinfinity Mar 25 '17 at 01:55
  • You said you are using Github as backup. I’m saying that’s not usually the best option. And you are correct; as far as Git is concerned, the branch you pull from and push to is always upstream. You could set those to different branches, in which case you pull from upstream and push to the “push default”, but it is rarely worth it. – Daniel H Mar 25 '17 at 02:06
  • @heretoinfinity, I've edited my answer to clarify why it is not logical to track downstream branches (and therefore the flag is `-u`). – André Sassi Mar 25 '17 at 11:25
0

Instead of talking about upstream/downstream, the remote/local git repo is more precise and easier to understand.

Github is the place where we can host our remote repo (or call it upstream).

Local repo (or call it downstream) is just the working copy that work for the remote repo.

So you can should reverse your understanding, that github is actually the main repo and local repo is just working copy. The reason including:

  • github can well mange the versions especially more than one developers work on this repo.
  • It’s the right meaning of DVCS (Distribute Version Control Systems), developers can work any time and any where on the working copies. You can compare the local version control systems and DVCS.

If you want to treat local repo as main(remote repo), you don’t need github any more. You just need to clone this repo to other directory and develop on the working copy, then commit/push to this remote repo.

The function git push -u origin master is push local master branch to github and set the tracking reference between local master and remote master branch (you can use git branch -vv to view the tracking relationship). And the situations to use git push -u are:

  • You init a git repo locally, so git treat it different from remote branch.
  • You cloned a remote repo, but you create a newbranch locally, so git doesn’t know which branch pushed to. You can use git push origin newbranch (create newbranch on remote and push local newbranch to it) or git push -u origin newbranch (create newbranch on remote and push local newbranch to it and set the tracking relationship between local newbranch and remote newbranch).
Marina Liu
  • 36,876
  • 5
  • 61
  • 74