Jeff King <p...@peff.net> writes:
> The point was that the meaning of "@{upstream}" (and "branch.*.merge")
> is _already_ "forked-from", and "push -u" and "push.default=upstream"
> are the odd men out. If we are going to add an option to distinguish the
> two branch relationships:
>
> 1. Where you forked from
>
> 2. Where you push to
>
> we should leave @{upstream} as (1), and add a new option to represent
> (2). Not the other way around.
That matches my feeling as well.
I am not sure if "push -u" is truly odd man out, though. It was an
invention back in the "you fetch from and push to the same place and
there is no other workflow support" days, and in that context, the
"upstream" meant just that: the place you fetch from, which happens
to be the same as where you are pushing to right now. If "push -u"
suddenly stopped setting the configuration to merge back from where
it is pushing, that would regress for centralized folks, so I am not
sure how it could be extended to also support triangular folks, but
I do think @{upstream} should mean "this is where I sync with to
stay abreast with others".
--
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
