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

From: Jeff King <peff@peff.net>
Date: Jan 7, 2014, 20:40 UTC
Message-ID: <20140107204035.GA27932@sigill.intra.peff.net>
In-Reply-To: <CALkWK0=g5-9r05vTkys8Tk7iv7PqPZJvMvkYsAOnN_F90Mtgxg@mail.gmail.com>

On Wed, Jan 08, 2014 at 02:00:44AM +0530, Ramkumar Ramachandra wrote:

Show 22 quoted lines

> On Wed, Jan 8, 2014 at 1:59 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
> > A very common workflow for preparing patches involves working off a
> > topic branch and generating patches against 'master' to send off to the
> > maintainer. However, a plain
> >
> >   $ git format-patch -o outgoing
> >
> > is a no-op on a topic branch, and the user has to remember to specify
> > 'master' explicitly everytime. This problem is not unique to
> > format-patch; even a
> >
> >   $ git rebase -i
> >
> > is a no-op because the branch to rebase against isn't specified.
> >
> > To tackle this problem, introduce branch.*.forkedFrom which can specify
> > the parent branch of a topic branch. Future patches will build
> > functionality around this new configuration variable.
> >
> > Cc: Jeff King <peff@peff.net>
> > Cc: Junio C Hamano <gister@pobox.com>
> > Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>

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.

Am I missing something?

-Peff