Jeff King <p...@peff.net> writes:
> 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.
I do not think there is no "want to declare" involved. If I
correctly recall how "push -u" came about, it was merely a way to
appease those who complained that their new branch created by
running "checkout -b branch origin/branch" has already set up the
branch.*.remote and branch.*.merge configurations nicely for them
and allow them to immediately go ahead and start using the
centralized "I merge from their 'branch' and push to that", but when
they create a new branch on their own and want to make the branch of
the same name at the origin to be the "upstream", they have to futz
with the configuration. The declaration was made long time ago when
we started using @{upstream}, and there is no new extra confusion.
>> 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?).
Correct; I am not saying "where do I publish" is never relevant. It
is just it is not something useful for "format-patch" to use as the
default fork-point.
> 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.
Yes. But most likely, if you always push a single branch to
multiple places, it won't be like you push it to only one of the
places today and another one tomorrow, leaving everybody out of
sync. Unless there is a site that is temporarily down, in which
case that one may stay behind, the normal state would be that all of
them point at the same commit (that is how I publish to multiple
places anyway).
>> 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.
Yeah, I think in the 2.0 world with pushdefault (i.e. triangular),
the default 'simple' turns into 'current'.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
