From: "Jeff King" <peff@xxxxxxxx> 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@xxxxxxxxxxxxxxx> 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. 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:
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html