Re: push.default: current vs upstream

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

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

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. Upstream 
is used often but isn't well defined (no obvious link anyway) - it's more of 
concept than a place (hence Andrew's option), while downstream is hardly 
mentioned at all.

For the push.default option can I suggest a different approach focused on
the beginner? If both current and upstream are potentially problematic, then
surely the default initially should be unset, so that a beginner's push is
refused with a pleasant message, e.g.
"  git push.default is unset,
   please use 'git push <remote> <branch>', or see its man page;
  or set the push.default to match your work style."

This offers the beginner a cause, an immediate solution, and guidance for
the long term. I deliberately called it a work style rather than workflow.

One work style for push.default could be "beginner" which would reduce the
message to:
-  git push.default is unset, use 'git push <remote> <branch>'

This gives the beginner time to learn their workflow, and gives a friendly 
version of the command.

While the expert user's regression would be to select _their_
current/upstream work style.

This approach does take the opposite route to most of the default settings
as it is about stopping beginners making major mistakes, rather than helping
them become productive.

One issue I had with the 'git push' man page is that 'refspec's are a fairly 
advanced (at least intermediate) concept that would confuse the beginner who 
is still getting to grips with their branches and remotes, so using the 'git 
push <remote> <branch>' version [*1*] will be friendlier to those beginners.

Philip

Yeah, I also took it to mean that the "downstream" of your "upstream"
would be where you started (though as you mentioned, it is not 1-to-1,
so that would not work anyway).

But this:

quoted

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.

is much more useful (and I already complained about the lack of
something like pushRemote recently). I just think it should not be
called "downstream", as it is not the reverse of upstream.

-Peff
--

[1] http://gitready.com/beginner/2009/01/21/pushing-and-pulling.html