Re: push.default: current vs upstream

[Andrew Sayers <andrew-git@pileofstuff.org>]

On 12/04/12 22:33, 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".
> 
> If you had something like this:
> 
> 	[remote "origin"]
>         	url = ...
>         [remote "destination"]
>                 pushURL = ...
> 
> 	[branch "topic"]
>         	remote = origin
>                 merge = refs/heads/master
> 		pushRemote = destination # new
>                 push = refs/heads/topic # new
> 
> you could express that asymmetric layout in a natural way.  When you say
> "git push" while on your "topic" branch, it will go to "destination"
> remote to update their "topic" branch.
> 
> Interesting...
> 

If "upstream" and "downstream" are ambiguous, it makes sense to avoid
the words altogether - you can't reduce ambiguity by adding more
definitions.  I'm replying to the above instead of your most recent
message because it might provide a fresh angle on the problem.

We already have language to describe "upstream" unambiguously, and an
intuitive way of describing the opposite of it, so specifying revisions
with the same language would help tie some things together and make git
easier to learn.  The only problem  is that we currently use two words
instead of one.

We could talk about @{remote}/@{pushRemote}, which I'd expect to be
intuitive to a beginner despite the inaccuracy - we already talk about
"remote repositories" and "remote tracking branches", so @{remote} would
be easy to guess.  Alternatively, @{merge}/@{push} would a bit more
accurate but a bit less obvious to people that don't really understand
merging yet (or are figuring out merge vs. rebase).  Or we could make up
some similar-but-distinct terms like @{mergeSource} and @{pushSink} that
reinforce the language above without overlapping.

	- Andrew