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

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

On 2009.12.08 18:14:07 +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.

The last sentence is wrong I think - it is still the branch head that
is updated.

But you don't rebase the branch head. Before the rebase, the branch head
doesn't reference the commits that get rebased. For example:

git checkout bar
git rebase --revisions foo bar

You "rebase" the commits in foo's history, but you update bar.

Yes, that's the who point of the patch.  The above applies a single
commit, foo, on top of current branch bar.

WRT the result, the above command should be equivalent to:
git checkout bar
git reset --hard foo
git rebase --root --onto ORIG_HEAD;

And here, the commits currently reachable through "bar" are rebased, and
"bar" also gets updated.

Björn

So this 
1. won't be very useful, as you show it is easy
   to achieve with existing commands.
2. interprets "foo" as branch name as opposed to
   revision range.

OTOH, rebase --revisions as I implemented is a "smarter cherry-pick" which
can't easily be achieved with existing commands, especially if you add
"-i".


-- 
MST