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@xxxxxxxxxx> > --- > > 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. 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html