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