Re: push.default: current vs upstream

"Philip Oakley" [off-list ref] writes:

From: "Jeff King" <redacted> Sent: Thursday, April 12, 2012 11:11 PM

quoted

On Thu, Apr 12, 2012 at 02:33:58PM -0700, Junio C Hamano wrote:

quoted

Andrew Sayers [off-list ref] writes:

quoted

So if the problem is that the documentation cues the reader to think
about upstreams but not to think about downstreams, the solution is to
find excuses to talk more about downstreams.  As far as I'm concerned
@{upstream} means "the place that commits come from when I `git pull`",
so it makes perfect sense to me that @{downstream} would mean "the
place
commits go to when I `git push`".

quoted

quoted

In a separate message I completely misunderstood what you meant by
"downstream".

It would be useful to have "upstream" and "downstream" clarified in
the documentation, say the Workflows man pages or some suitable
place.

Perhaps, but I am not convinced.  I am not convinced that it is a bad idea
either, so I'll think aloud for several paragraphs, and probably will not
reach a conclusion in this message. Just a food for thought...

I think the word "downstream" has rarely been used in the context of Git,
but because it is a natural opposite for the word "upstream", I've seen it
used when people talk about others who fork from them, e.g. Linus can call
his lieutenants his downstream.

The word "upstream" almost always refers to "the place the updates from
others come to me from".  Linus is the upstream for his lieutenants---the
lieutenants pull from Linus.  In the shared repository "everybody pulls
from there to get updates from others, and everybody pushes there to
propagate their own work to others" setting, the shared repository is the
upstream for the project participants---again, they pull from there.

Notice however that the word "upstream" is meaningless for the integrator
with the above definition of the word.  "The place the updates from others
come to Linus from" ought to be his "upstream", but the workflow does not
go like so. Linus does not have a fixed "upstream" he pulls from before
he starts his day. For that matter, the lieutenants are not supposed to
pull from Linus every day before they start their work, either, but when
they need to synchronize with the upstream, they pull from Linus, so in
that sense, the word "upstream" means something to them.

I suspect that using the word "downstream" to mean "the place the result
of my work is pushed to" will only add to the confusion.

In a distributed "kernel-like" workflow, the lieutenants obviously do not
push to Linus's repository. If we raise the level of discussion to talk
about the flows of data, ignoring the difference of mechanism used
(i.e. "push" vs "format-patch | send-email"), the work by lieutenants is
still fed back to their "upstream".  They "upstream" (verb) the result of
their work.

Perhaps it was a mistake to use the word "upstream" in a shared repository
workflow, which invites the confusing word "downstream". In that context,
there is not really an "up" vs "down" relationship.  "shared" vs "mine"
relationship is all that exists in that context.