rebase discards a still-valid recorded base after the parent's history is edited, replaying the parent's old commits
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 52/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- git, go
- Bereich
- cli, developer-experience
Rechercherichtung
Die Payload nennt keine Implementierungsdateien oder Tests. Beginne beim Einstiegspunkt gh stack rebase und reproduziere den Fall eines geänderten Parents; verfolge dann, wie die aufgezeichnete Basis akzeptiert oder verworfen wird. Fertig ist es, wenn B nach Änderungen an der Parent- oder Trunk-Historie nur B1 erneut anwendet, einschließlich der Variante mit stiller Korruption, mit Regressionstests für beide Fälle.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
(This issue was AI generated but I have reviewed it, understood it, and I'm accountable for its content.)
Version: gh-stack v0.1.0.
Setup: trunk main; stack A ← B (gh stack init A B); A has commit A1 modifying f.txt, B has commit B1 adding g.txt.
Repro: amend A1 on A (change f.txt, keep the message), then gh stack rebase.
Expected: B is rebased by replaying only B1 onto the amended A — B's recorded base (old A tip) is still an ancestor of B and delimits exactly B's own commits.
Actual: the recorded base is discarded (apparently because it is no longer in A's history), the boundary falls back to merge-base(A, B) — below the amendment — and the old A1 is replayed onto the amended A: a bogus conflict in f.txt.
Worse variant (silent corruption): if the amendment only removes part of A1 (e.g. A1 touched f.txt + extra.txt, and the amend drops the extra.txt change), the old A1 replays cleanly: B ends up with a duplicated commit and the removed extra.txt resurrected — reported as success.
Suggested fix: accept a recorded base as the --onto boundary whenever it is an ancestor of the branch being rebased; membership in the parent's current history should not be required. This matches Graphite's restack semantics and is what makes stacks robust under history editing.
The same failure triggers when the trunk's history is edited (e.g. a commit below the stack is amended via fixup): the whole old trunk segment is replayed into the bottom stack branch.
- Vorherrschende Sprache
- Go
- Sterne
- 1.5k
- Forks
- 73
- Ø Merge
- 1 T. 8 Std.
- Gemergte PRs (30 T.)
- 5
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus github/gh-stack
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 92/100
-
feature request topic: cli - general
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
feature request topic: auto-merge
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
bug topic: docs
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 68/100
Alle Issues in github/gh-stack
Ähnliche Issues
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
-
Bob Shell support Offenenhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
santhosh-tekuri/jsonschema#276 ·