rebase discards a still-valid recorded base after the parent's history is edited, replaying the parent's old commits
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 52/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- git, go
- Área
- cli, developer-experience
Línea de trabajo
El payload no menciona archivos de implementación ni pruebas. Empieza en el punto de entrada gh stack rebase y reproduce el caso de un parent modificado; después, sigue cómo se acepta o se descarta la base registrada. El trabajo estará terminado cuando B vuelva a aplicar únicamente B1 después de modificaciones en el historial del parent o de trunk, incluida la variante de corrupción silenciosa, con cobertura de regresión para ambos casos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
(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.
- Lenguaje dominante
- Go
- Estrellas
- 1.5k
- Forks
- 73
- Merge medio
- 1 d 8 h
- PR fusionados (30 d)
- 7
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de github/gh-stack
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
-
feature request topic: cli - general
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
feature request topic: auto-merge
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
bug topic: docs
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
Todos los issues de github/gh-stack
Issues similares
-
area/dev-productivity area/disaster-recovery area/ipcei kind/enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
kind/bug status/0-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
🤔 refinement needed
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
equinor/radix-operator#1979 ·