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
fix(restack): prevent stale fork points from triggering incorrect --onto rebases (#83)
* fix(restack): prevent stale fork points from triggering incorrect --onto rebases
When a stored fork point fell behind the actual divergence point (e.g.
after a manual `git rebase` or a conflict-then-continue), the
`useOnto` logic would incorrectly trigger `git rebase --onto` with
the stale fork point as the upstream boundary. This replayed commits
already present in the parent, causing spurious conflicts and dropped
patches.
Three fixes:
- **Ancestor check in `useOnto` decision**: distinguish a stale fork
point (ancestor of merge-base → use simple rebase) from a genuinely
rewritten parent (divergent history → `--onto` is correct).
- **Refresh fork point on "already up to date"**: when `NeedsRebase`
returns false, update the fork point to the parent tip so external
rebases don't leave it permanently stale.
- **Update fork point in `continue`**: after resolving a conflict,
the branch that was being rebased never had its fork point refreshed;
now it does.
Adds `Git.IsAncestor()` helper and five new tests covering all three
paths plus a regression guard for the legitimate `--onto` case.
* fix(restack): handle GC'd fork points gracefully with a warning
When a stored fork point commit has been garbage collected (e.g. after
a history rewrite followed by aggressive `git gc`), the previous code
silently fell through to a plain rebase. Now it emits a warning so the
user knows why `--onto` wasn't used, then falls back to a simple
rebase as before.
0 commit comments