From: Jeff King Date: Tue, 07 Jan 2014 20:40:35 GMT Subject: Re: [RFC/PATCH] format-patch: introduce branch.*.forkedFrom Message-ID: <20140107204035.GA27932@sigill.intra.peff.net> In-Reply-To: On Wed, Jan 08, 2014 at 02:00:44AM +0530, Ramkumar Ramachandra wrote: > On Wed, Jan 8, 2014 at 1:59 AM, Ramkumar Ramachandra 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 > > Cc: Junio C Hamano > > Signed-off-by: Ramkumar Ramachandra 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