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

From: Jeff King <peff@peff.net>
Date: Jan 7, 2014, 21:16 UTC
Message-ID: <20140107211645.GC28102@sigill.intra.peff.net>
In-Reply-To: <CALkWK0mGPhU-8vVg+xY-MGWNstxoXSU9MGQiNzyFN+-Q6Bw28A@mail.gmail.com>

On Wed, Jan 08, 2014 at 02:32:10AM +0530, Ramkumar Ramachandra wrote:

Show 14 quoted lines

> > 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.

Thanks for a concrete example.

I definitely respect the desire to reuse the existing tooling we have for @{u}. At the same time, I think you are warping the meaning of @{u} somewhat. It is _not_ your upstream here, but rather another version of the branch that has useful changes in it. That might be splitting hairs a bit, but I think you will find that the differences leak through in inconvenient spots (like format-patch, where you really _do_ want to default to the true upstream).

If we add "@{publish}" (and "@{pu}"), then it becomes very convenient to refer to the ram/ version of your branch. That seems like an obvious first step to me. We don't have to add new config, because "branch.*.pushremote" already handles this.

Now you can do "git rebase @{pu}" which is nice, but not _quite_ as nice as "git rebase", which defaults to "@{u}". That first step might be enough, and I'd hold off there and try it out for a few days or weeks first. But if you find in your workflow that you are having to specify "@{pu}" a lot, then maybe it is worth adding an option to default rebase to "@{pu}" instead of "@{u}".

You end up in the same place ("git rebase" without options does what you want), but I think the underlying data more accurately represents what is going on (and there is no need to teach "format-patch" anything special).

-Peff