Robert Dailey <rcdailey.li...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html