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

[George Spelvin <lkml@SDF.ORG>]

On Tue, Apr 07, 2020 at 05:16:50AM -0400, Sebastien Bruckert wrote:
> Hmmm so you need some way to move C before your actual commit. To make
> it like a pseudo command, some kind of "git rebase --reattach C
> --after A"? This seems closer to your original idea.

That seems too special-purpose and hard to remember.  The standard
rebase -i operation (generate a todo list and drop me into an editor)
is perfectly adequate and more familiar.  This is a very manual operation, 
after all.  ("-i" for "interactive" means "manual".)

> Or why not modify "--edit-todo" to get commits from before your actual
> point? It could works like this:
> 
> Before:
> ```
> #pick b2a96fe O
> #pick acb7459 A
> #pick 0dac4a4 B
> edit 1f54e51 C
> edit cda2a7e D
> ```
> 
> After:
> ```
> #pick b2a96fe O
> edit 1f54e51 C
> pick acb7459 A
> pick 0dac4a4 B
> edit cda2a7e D
> ```
> 
> So that you are still at C, but keeping the changes you made before on
> A and B, and going through them only if you have conflicts.

Because the only reason this is interesting assumes that A and B have 
changed!  If I didn't intend to modify A somehow, I wouldn't have included 
it in the rebase range.  They're now edited patches A' and B'.  So the
state I want to get to is:

#pick b2a96fe O
#pick acb7459 A
#pick 0dac4a4 B
reset b2a96fe O
edit 1f54e51 C
pick 7f0bcab A'
pick fcd3c62 B'
edit cda2a7e D

where it will pick the versions of A and B that include the edits I've
already made.

Now, having the original commits mentioned in comments is useful, in case 
I made a mess of the edit and want to revert it.  E.g. I can certainly see 
realizing, three commits later in the rebase, that I recolved a conflict 
wrong and should re-do it.  Although this can probably be handled with a 
fixup.