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
Heal stacks whose recorded base was already corrupted
The previous commit stops `gh stack push` from recording a base the branch does
not contain, but every stack that has already been through that path still
carries a bad value on disk. Those stacks would keep hitting the conflict on
their next rebase, because neither the parent's current tip nor the recorded
base is a boundary the branch actually has.
`resolveOntoOldBase` now also considers `git merge-base --fork-point`, which
reads the parent's reflog and so still finds where the branch diverged after
the parent was amended, rebased, or force-pushed — exactly the record the stack
file lost. It is only a candidate: the ancestry check still gates it, and a
fresh clone or an expired reflog simply falls through to the merge bases as
before.
Verified on a real stack whose metadata had been corrupted by the previous
build: the rebase now completes, replaying one commit instead of two, and the
recorded bases are genuine ancestors again afterwards.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f5959297-80fd-4732-aeae-aa9a4b6a7755
0 commit comments