Robert Dailey <rcdailey.lists@xxxxxxxxx> writes: > Maybe I'm misunderstanding something here and you can help me out. > > All the reading I've done (mostly github) says that 'upstream' points > to the authoritative repository that you forked from but do not have > permissions to write to. 'origin' points to the place you push your > changes for pull requests (the fork). I do not know if that is how GitHub teaches people, but I would have to say that these are strange phrasing. I suspect that part of their documentation was written long time ago, back when nobody on the GitHub side were involved in design (let alone implementation) of Git, and I would take it with a grain of salt. Having said that, here is a summary of the current support for referring to different repositories in Git: The word 'origin' refers to where things originate from; a place you push to is where things go, so it makes no sense to use that word to refer to the repository where you publish your work result. The 'origin' may or may not be where you can push (or you would want to push) to. It is where you 'pull' from to synchronize with the 'upstream'. The 'upstream' in SCM context refers to those who control a logically more authoritative history than you, whose work you derive your work from, i.e. synonymous to 'origin'. For people like Linus (i.e. he may pull from others but that is to take in changes made as derived work; he does not pull to grab more authoritative work), there is no need to say 'upstream'; or you can consider he is his own 'upstream'. For those who use CVS-style central repository model (i.e. they would pull from that single central shared repository, and push their work back to the same repository), 'origin' are writable to them and they push to them. For people with CVS-style central shared repository model, their central repository is their 'upstream' with respect to their local copy. Since these two classes of people need just one other repository to refer to, we just used 'origin' when we did the very initial version of "git clone", and these users can keep using that name to refer to that single other repository they interact with. The support for the triangular workflow in which you pull from one place and push the result of work to another, which the configuration variable 'remote.pushdefault' is a part of, is relatively a more recent development in Git. I am not sure we have added an official term to our glossary to refer to the repository you push your work result to, but in the discussions we have seen phrases like 'publishing repository' used, I think. It must be writable by you, of course, and it may or may not be the same as the 'origin' repository. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html