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@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. 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 -- 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