Re: push.default: current vs upstream

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 13, 2012, 19:31 UTC
Message-ID: <7vmx6f2ztd.fsf@alter.siamese.dyndns.org>
In-Reply-To: <A13E3113738743C6B002BB6B076E1FEE@PhilipOakley>

"Philip Oakley" <philipoakley@iee.org> writes:

Show 19 quoted lines

> From: "Jeff King" <peff@peff.net> Sent: Thursday, April 12, 2012 11:11 PM
>> On Thu, Apr 12, 2012 at 02:33:58PM -0700, Junio C Hamano wrote:
>>
>>> Andrew Sayers <andrew-git@pileofstuff.org> writes:
>>>
>>> > 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`".
>
>>> 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.