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

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:

quoted

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

quoted

On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:

quoted

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?

quoted

quoted

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 :)