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".
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
--
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