Replies: 1 comment 1 reply
-
"upstream" and "downstream" are not really git terms. They refer to how software is developed. As an example, Debian is an upstream to us: we integrate opencpn into Debian. This also means that when Debian changes things we incorporate this changes. In the same way the main opencpn project is upstream w r t plugins. Plugins are integrated in OpenCPN much like OpenCPN is integrated in Debian. So, "upstream" and "downstream" are roles. Another typical example of these roles is a dev which forks opencpn and makes some changes. Here, the developer fork is downstream w r t the master branch which is upstream. Sometimes "upstream" is used a verb: eventually the dev upstreams her changes by making a PR (i. e., she sends her own changes upstream). And so on. No git so far. As for git, there is the notion of remotes. A remote is basically a shorthand for a repository url. There are some strong conventions here. The "origin" remote is the repository where the developer has write access. In the opencpn case, it's almost always a fork of OpenCPN. But for a plugin which the dev maintains, "origin" will refer to the main plugin repo (no fork). The "upstream" remote is the source of updates to the software we use. In the OpenCPN case, it refers to OpenCPN/OpenCPN on github. As developer we import changes from upstream and issues PRs to this repo. That is, upstream is typically read-only. Better explanation: https://stackoverflow.com/questions/2739376 |
Beta Was this translation helpful? Give feedback.
-
If your own personal use is consistent, these terms can be switched with no consequence, butit would be nice to have "common practice" standard definitions here.
Beta Was this translation helpful? Give feedback.
All reactions