Re: [PATCH RFC] rebase: add --revisions flag
- From
Björn Steinbrink <b.steinbrink@gmx.de>
- Date
- Dec 8, 2009, 19:13 UTC
- Message-ID
- <20091208191324.GA4200@atjola.homenet>
- In-Reply-To
- <20091208164904.GB32204@redhat.com>
On 2009.12.08 18:49:04 +0200, Michael S. Tsirkin wrote:
Show 29 quoted lines
> 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