rebase discards a still-valid recorded base after the parent's history is edited, replaying the parent's old commits
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 52/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- git, go
- Ambito
- cli, developer-experience
Direzione di ricerca
Il payload non indica file di implementazione né test. Parti dall’entry point gh stack rebase e riproduci il caso del parent modificato, quindi traccia come la base registrata viene accettata o scartata. Il lavoro è completo quando B riesegue solo B1 dopo modifiche alla cronologia del parent o di trunk, inclusa la variante con corruzione silenziosa, con copertura di regressione per entrambi i casi.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
(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.
- Lingua principale
- Go
- Stelle
- 1.5k
- Fork
- 73
- Merge medio
- 1g 8h
- PR unite (30g)
- 7
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di github/gh-stack
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
-
feature request topic: cli - general
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
feature request topic: auto-merge
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
bug topic: docs
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 68/100
Tutte le issue di github/gh-stack
Issue simili
-
textual definition
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
geneontology/go-ontology#32653 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
-
needs design
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Priority/High ready-for-agent Severity/Major Type/Bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100