Re: [PATCH RFC] rebase: add --revisions flag

From: Michael S. Tsirkin <mst@redhat.com>
Date: Dec 8, 2009, 16:11 UTC
Message-ID: <20091208161142.GA32045@redhat.com>
In-Reply-To: <20091208160822.GA1299@atjola.homenet>

On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:

Show 26 quoted lines

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

> But generally, I'd say it would be better to add such a range feature to
> cherry-pick than abusing rebase for that.
> 
> Björn

The reason to use rebase is that I often want to combine this with -i flag, editing patches as they are applied.

-- 
MST