Re: [RFC/PATCH] format-patch: introduce branch.*.forkedFrom
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 7, 2014, 20:48 UTC
- Message-ID
- <xmqqzjn7bjre.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20140107204035.GA27932@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 11 quoted lines
> 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".