git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Michael S. TsirkinNext: Michael S. Tsirkin
Message 6 of 43 in “rebase: add --revisions flag”
  1. rebase: add --revisions flagMichael S. Tsirkin, Dec 8, 2009
  2. Björn SteinbrinkDec 8, 2009
  3. Michael S. TsirkinDec 8, 2009
  4. Björn SteinbrinkDec 8, 2009
  5. Michael S. TsirkinDec 8, 2009
  6. Björn SteinbrinkDec 8, 2009
  7. Michael S. TsirkinDec 8, 2009
  8. Björn SteinbrinkDec 8, 2009
  9. Michael S. TsirkinDec 8, 2009
  10. Björn SteinbrinkDec 8, 2009
  11. Michael S. TsirkinDec 8, 2009
  12. Björn SteinbrinkDec 9, 2009
  13. Michael S. TsirkinDec 9, 2009
  14. Miles BaderDec 9, 2009
  15. Junio C HamanoDec 8, 2009
  16. Sverre RabbelierDec 8, 2009
  17. Christian CouderDec 9, 2009
  18. Christian CouderDec 9, 2009
  19. Sverre RabbelierDec 9, 2009
  20. Peter KreftingDec 9, 2009
  21. Michael S. TsirkinDec 9, 2009
  22. Peter KreftingDec 9, 2009
  23. Björn SteinbrinkDec 9, 2009
  24. Andreas SchwabDec 9, 2009
  25. Björn SteinbrinkDec 9, 2009
  26. Michael S. TsirkinDec 9, 2009
  27. Björn SteinbrinkDec 9, 2009
  28. Junio C HamanoDec 9, 2009
  29. Björn SteinbrinkDec 10, 2009
  30. Junio C HamanoDec 10, 2009
  31. Björn SteinbrinkDec 11, 2009
  32. Peter KreftingDec 9, 2009
  33. Björn SteinbrinkDec 9, 2009
  34. Peter KreftingDec 10, 2009
  35. Björn SteinbrinkDec 10, 2009
  36. Michael S. TsirkinDec 9, 2009
  37. Matthieu MoyDec 9, 2009
  38. Matthieu MoyDec 9, 2009
  39. Michael S. TsirkinDec 9, 2009
  40. Björn SteinbrinkDec 9, 2009
  41. Michael S. TsirkinDec 9, 2009
  42. Junio C HamanoDec 9, 2009
  43. David KågedalDec 13, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.