Note that the terms "upstream" and "downstream" are quite generic except when using specific Git commands or suffixes. For instance, main@{u}
or main@{upstream}
refers to the --set-upstream-to=
name associated with branch name main
.
George Rylkov's comment link to Definition of "downstream" and "upstream" expounds on the meaning of the slightly-effable version of "upstream".
The Git notion of an upstream is simply a string—consisting either of a local branch name like feature
, or a remote-tracking name like origin/main
for instance—that is associated with a branch name. The branch name must exist, and the local or remote-tracking name must also exist in order for git branch --set-upstream-to
to set it. But since names—whether local branch names, tag names, remote-tracking names, or indeed any other kind of names—can be created and destroyed at your whim, it's possible to set an upstream name at some point:
git branch foo
git branch bar
git branch --set-upstream-to=bar foo
(now [local] branch foo
has [local] branch bar
set as its upstream) and then delete the upstream:
git branch -D bar
If you do this, git branch -vv
will list the upstream setting, but also call it "gone".
The upstream setting of a branch name, if it has one at all, is merely used to make some other things in Git more convenient. So it's not harmful to lack one, nor is it harmful to have a "gone" upstream. However, it's not helpful either: the helpful convenience—if you see it as convenient and helpful, which is a matter of personal test—only occurs if the upstream setting of a branch name isn't "gone".
What convenience is that? See Why do I need to do `--set-upstream` all the time?, Make an existing Git branch track a remote branch?, and Why do I have to "git push --set-upstream origin <branch>"?
(Note, too, that in Git tradition, git rebase
(ab)uses the term upstream for yet another purpose.)