From: Michael S. Tsirkin <mst@redhat.com>
Date: Tue, 08 Dec 2009 16:49:04 GMT
Subject: Re: [PATCH RFC] rebase: add --revisions flag
Message-ID: <20091208164904.GB32204@redhat.com>
In-Reply-To: <20091208164113.GB2005@atjola.homenet>

On Tue, Dec 08, 2009 at 05:41:13PM +0100, Björn Steinbrink wrote:
> On 2009.12.08 18:11:44 +0200, Michael S. Tsirkin wrote:
> > On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> > > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > > > Add --revisions flag to rebase, so that it can be used
> > > > to apply an arbitrary range of commits on top
> > > > of a current branch.
> > > > 
> > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > ---
> > > > 
> > > > I've been wishing for this functionality for a while now,
> > > > so here goes. This isn't yet properly documented and I didn't
> > > > write a test, but the patch seems to work fine for me.
> > > > Any early flames/feedback?
> > > 
> > > This pretty much reverses what rebase normally does. Instead of "rebase
> > > this onto that" it's "'rebase' that onto this". And instead of updating
> > > the branch head that got rebased, the, uhm, "upstream" gets updated.
> > > 
> > > Also, AFAICT this needs to be called like this:
> > > git rebase --revisions foo..bar HEAD
> > > 
> > > Changing the meaning of the <upstream> argument and relying on the fact
> > > that <newbase> defaults to <upstream>. If such a thing gets added, it
> > > should rather work like --root, not using <upstream> at all, but --onto
> > > <newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto
> > > optional, as it's reversed WRT what it does compared to the usual
> > > rebase.
> > 
> > Sorry, I had trouble parsing the above.  Could you suggest e.g. how the
> > help line should look?
> 
> Current:
> git rebase [-i | --interactive] [options] [--onto <newbase>]
> 	<upstream> [<branch>]
> git rebase [-i | --interactive] [options] --onto <newbase>
> 	--root [<branch>]
> 
> Add:
> git rebase [-i | --interactive] [options] --revisions <range> [<branch>]
> 
> (Thinking about it, I guess an explicit --onto makes no sense with the
> --revisions flag)

I agree.
So this is different from what I implemented basically only in that
we should disallow combining --onto with --revisions. Right?

> > > But generally, I'd say it would be better to add such a range feature to
> > > cherry-pick than abusing rebase for that.
> > 
> > The reason to use rebase is that I often want to combine
> > this with -i flag, editing patches as they are applied.
> 
> Hm, well, your patch didn't touch git-rebase--interactive.sh ;-)
> 
> Björn

Ah, I was wondering why it doesn't work :)