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.
