Re: [PATCH RFC] rebase: add --revisions flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]