Re: [RFC/PATCH] format-patch: introduce branch.*.forkedFrom

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Jan 7, 2014, 21:02 UTC
Message-ID: <CALkWK0mGPhU-8vVg+xY-MGWNstxoXSU9MGQiNzyFN+-Q6Bw28A@mail.gmail.com>
In-Reply-To: <20140107204035.GA27932@sigill.intra.peff.net>

Jeff King wrote:

Show 15 quoted lines

> I have not carefully read some of the later bits of the discussion from
> last night / this morning, so maybe I am missing something, but this
> seems backwards to me from what Junio and I were discussing earlier.
>
> 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.

I have a local branch 'forkedfrom' that has two "sources": 'master' and 'ram/forkedfrom'. 'ram/forkedfrom' isn't a "dumb" publish-point: the relationship information I get between 'forkedfrom' and 'ram/forkedfrom' is very useful; it's what helps me tell how my re-roll is doing with respect to the original series; I'd often want to cherry-pick commits/ messages from my original series to prepare the re-roll, so interaction with this source is quite high. On the other hand, the relationship information I get between 'forkedfrom' and 'master' is practically useless: 'forkedfrom' is always ahead of 'master', and a divergence indicates that I need to rebase; I'll never really need to interact with this source.

I'm only thinking in terms of what infrastructure we've already built: if @{u} is set to 'ram/forkedfrom', we get a lot of information for free _now_. If @{u} is set to 'master', the current git-status is unhelpful.