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

Re: Feature request: rebase -i inside of rebase -i

From
GSGeorge Spelvin <lkml@sdf.org>
Date
Mar 30, 2020, 18:18 UTC
Message-ID
<20200330181812.GB9199@SDF.ORG>
In-Reply-To
<0eef4721-1646-48f2-1102-71159d06b049@iee.email>
On Mon, Mar 30, 2020 at 03:01:28PM +0100, Philip Oakley wrote:
Show 23 quoted lines
> Perhaps we can go the other way on this one.
> 
> I'd agree that attempting to nest (misunderstood mistaken) rebases is
> digging a too deep hole that we'd not get out of. However we do have
> other rebases available, specifically the "rebasing merges"
> https://git-scm.com/docs/git-rebase#_rebasing_merges.
> 
> I know rebasing merges is way down the man page, but it has all the
> power and flexibility needed _if_ we can step across from the mistaken
> rebase step (we are at the command prompt aren't we?) into the rebasing
> merge mode.
> 
> This will require a little bit of expansion of the insn (instruction)
> sheet so as to _include commented lines of the rebase steps completed_
> so far, along with the labels, resets, merges, etc, so that the user can
> _see_ where they they are within their failed progress (along with a
> title line telling them their initial command and that they are now on a
> rebasing merge insn;-).
> 
> From there they can update the insn to reset back to the correct point,
> redo the correct picks, and then get back to their remaining rebase steps.
> 
> It's a thought anyway.

I'm confused. *How* does --rebase-merge mode help? You're saying "hey, if we use this, it solves the issue" but I don't see how to pound this nail with that screwdriver.

I don't see how creating a branching history helps, and I don't see how to use the reset/label/merge commands to do anything but create a branching history.

I suppose it is possible to use the "reset" command in isolation to describe the jump to a new base. So you could have a history of:

# Command already executed: # reset base # pick A # pick B # pick C # label rebase-1 User asked for a nested rebase # reset A'

# Commands pending: pick B' pick C' # rebase-2 complete, resume rebase-1 pick D pick E

Is that what you were getting at?

I was thinking of it being implicit, but it might be nice for the initial "reset" in each rebase to be explicit, *and not yet executed during the initial todo edit*.

That makes it really clear that deleting the todo list entirely results in no change to the tree.

Previous: Philip OakleyNext: Philip Oakley
Message 23 of 25 in “Feature request: rebase -i inside of rebase -i”
  1. George SpelvinMar 20, 2020
  2. Junio C HamanoMar 20, 2020
  3. George SpelvinMar 20, 2020
  4. Johannes SchindelinMar 21, 2020
  5. George SpelvinMar 21, 2020
  6. Johannes SchindelinMar 25, 2020
  7. George SpelvinMar 26, 2020
  8. Johannes SchindelinMar 28, 2020
  9. George SpelvinMar 28, 2020
  10. George SpelvinMar 31, 2020
  11. Philip OakleyMar 31, 2020
  12. Phillip WoodMar 31, 2020
  13. Philip OakleyApr 1, 2020
  14. Phillip WoodApr 7, 2020
  15. Johannes SchindelinApr 4, 2020
  16. Johannes SchindelinApr 4, 2020
  17. George SpelvinApr 4, 2020
  18. Sebastien BruckertApr 6, 2020
  19. George SpelvinApr 6, 2020
  20. Sebastien BruckertApr 7, 2020
  21. George SpelvinApr 7, 2020
  22. Philip OakleyMar 30, 2020
  23. George SpelvinMar 30, 2020
  24. Philip OakleyMar 30, 2020
  25. Johannes SixtMar 21, 2020

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.