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

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

From
MTMichael S. Tsirkin <mst@redhat.com>
Date
Dec 8, 2009, 16:49 UTC
Message-ID
<20091208164904.GB32204@redhat.com>
In-Reply-To
<20091208164113.GB2005@atjola.homenet>
On Tue, Dec 08, 2009 at 05:41:13PM +0100, Björn Steinbrink wrote:
Show 43 quoted lines
> 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@redhat.com>
> > > > ---
> > > > 
> > > > 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?

Show 9 quoted lines
> > > 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 :)
Previous: Björn SteinbrinkNext: Björn Steinbrink
Message 5 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.