Description
Take this todo list, for example:
label onto
# Branch dscho
reset onto
pick a123 first
label dscho
# Branch avar
reset onto
pick b789 second
label avar
reset onto
merge -C c124 dscho
merge -C d314 avar
In other words: two branches, both one patch deep, both merged, one after the other. Now,
if you insert pick abc zeroth
before the first pick
, obviously the first branch would no longer be skippable, but the second one totally would be!
Since we are not performing a linear rebase, the skip_unnecessary_picks()
function has no prayer of helping us here.
To remedy this, we would probably need code in pick_commits()
, right where TODO_RESET
is handled, that would:
-
parse the argument (this is currently done in
do_reset()
and would have to be refactored out) and pretend that it isHEAD
, -
look at the following command: if it is
-
a
pick
, and if its parent agrees withHEAD
, pretend that thepick
was actually areset
, update the pretendedHEAD
and keep looking at the next command, -
a
merge
, and if its option was-C <orig-merge>
(not lower-case-c
!), and if its parent agrees withHEAD
, and if its merge head(s) agree with the original merge commit's (if any), pretend that it was actually areset <orig-merge>
, update the pretendedHEAD
and keep looking at the next command, -
a
label
, perform it, but with the pretendedHEAD
, and keep looking for the next command, -
a
reset
, update thedone
andgit-rebase-todo
files and start the entire spiel from the top, -
otherwise perform the reset.
-
-
all while skipping, this code would need to take care of updating the
done
andgit-rebase-todo
files, -
if a
reset
is necessary, and if it fails, thedone
andgit-rebase-todo
files should not be updated, but the originalreset
should be re-scheduled, and -
since this adds quite a bit of code, it should probably be done in a separate function.
Instead of tapping into the TODO_RESET
code block, it might make more sense, though, to start at the top of the loop, with whatever HEAD
is at the moment.