You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 is HEAD,
look at the following command: if it is
a pick, and if its parent agrees with HEAD, pretend that the pick was actually a reset, update the pretended HEAD 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 with HEAD, and if its merge head(s) agree with the original merge commit's (if any), pretend that it was actually a reset <orig-merge>, update the pretended HEAD and keep looking at the next command,
a label, perform it, but with the pretended HEAD, and keep looking for the next command,
a reset, update the done and git-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 and git-rebase-todo files,
if a reset is necessary, and if it fails, the done and git-rebase-todo files should not be updated, but the original reset 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.
The text was updated successfully, but these errors were encountered:
Take this todo list, for example:
In other words: two branches, both one patch deep, both merged, one after the other. Now,
if you insert
pick abc zeroth
before the firstpick
, 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 whereTODO_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, andsince 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 whateverHEAD
is at the moment.The text was updated successfully, but these errors were encountered: