On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote:
> > I wonder if it is too late to try to clarify this dual usage. It kind of
> > seems like the push config is "this is the place I publish to". Which,
> > in many workflows, just so happens to be the exact same as the place you
> > forked from. Could we introduce a new branch.*.pushupstream variable
> > that falls back to branch.*.merge? Or is that just throwing more fuel on
> > the fire (more sand in the pit in my analogy, I guess).
> >
> > I admit I haven't thought it through yet, though. And even if it does
> > work, it may throw a slight monkey wrench in the proposed push.default
> > transition.
>
> Yeah, when I say "upstream", I never mean it as "where I publish".
> Your upstream is where you get others' work from.
That's my thinking, as well, but it means the "upstream" push.default is
nonsensical. I've thought that all along, but it seems like other people
find it useful. I guess because they are in a non-triangular,
non-feature-branch setup (I suppose you could think of a central-repo
feature-branch workflow as a special form of triangular setup, where
the remote is bi-directional, but the branch names are triangular).
If we want to declare "push -u" and "push.default=upstream" as tools for
certain simple bi-directional workflows, that makes sense. But I suspect
it may cause extra confusion when people make the jump to using a
triangular workflow.
> For a "push to somewhere for safekeeping or other people to look at"
> triangular workflow, it does not make any sense to treat that "I
> publish there" place as an upstream (hence having branch.*.remote
> pointing at that publishing point).
You _might_ treat it the same way we treat the upstream, in some special
cases. For example, when you say "git status", it is useful to see how
your topic and the upstream have progressed (i.e., do I need to pull
from upstream?). But you may _also_ want to know how your local branch
differs from its pushed counterpart (i.e., do I have unsaved commits
here that I want to push up?).
So having two config options might help with that. Of course, your "push
upstream" (or whatever you want to call it) does not logically have one
value. You may push to several places, and would want to compare to
each.
> Once you stop doing that, and
> instead using branch.*.remote = origin, and branch.*.merge = master,
> where 'origin' is not your publishing point, @{u} will again start
> making sense, I think.
>
> And I thought that is what setting "remote.pushdefault" to the
> publishing point repository was about.
If that were sufficient, then we would just need "push.default =
current", and not "upstream" (nor "simple"). I lobbied for that during
the discussion, but people seemed to think that "upstream" was
better/more useful. Maybe it was just because remote.pushdefault did not
exist then.
-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