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 9, 2009, 10:38 UTC
Message-ID
<20091209103850.GD2977@redhat.com>
In-Reply-To
<7vfx7lcj18.fsf@alter.siamese.dyndns.org>
On Tue, Dec 08, 2009 at 12:22:59PM -0800, Junio C Hamano wrote:
Show 27 quoted lines
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > Add --revisions flag to rebase, so that it can be used
> > to apply an arbitrary range of commits on top
> > of a current branch.
> 
> Many people wanted to have "pick many commits onto the current HEAD" and I
> think it would be a natural, uncontroversial and welcome addition to allow
> "git cherry-pick A..B".  In fact, historically, people who wanted to have
> "pick many commits" complained that the "rebase" interface was backwards,
> because it works in the _wrong_ direction for _their_ usecase.  Of course,
> when you _are_ rebasing a branch on top of some other branch, the way
> "rebase" currently works is the _right_ direction.
> 
> But I think it is a reasonable thing to _implement_ the feature to
> range-pick commits reusing the sequencing logic already in "rebase" and
> "rebase -i".  That essentially is what we wanted to do with "git
> sequencer" that would be a sequencing logic backend shared among rebase,
> cherry-pick, and perhaps am.
> 
> So perhaps a good way to move forward is to teach "git cherry-pick A..B"
> to be a thin wrapper that invokes a new hidden mode of operation added to
> "rebase" that is not advertised to the end user.
> 
> I would suggest calling the option to invoke that hidden mode not
> "--revisions", but "--reverse" or "--opposite" or something of that
> nature, though.  It makes "rebase" work in different direction.

cherry-pick is a binary though while rebase is a shell script. Should I just exec git rebase? git-rebase?

-- 
MST
Previous: Björn SteinbrinkNext: Matthieu Moy
Message 36 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.