On 2009.12.08 18:49:04 +0200, Michael S. Tsirkin wrote: > On Tue, Dec 08, 2009 at 05:41:13PM +0100, Björn Steinbrink wrote: > > > > 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? It also drops <upstream>, because that makes no sense with --revisions. So the only mandatory argument is the revision range. 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