gh stack rebase --continue doesn't report new conflicts hit while resuming a multi-commit branch rebase
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 72/100
Rechercherichtung
Beginne in cmd/rebase.go bei continueRebase und vergleiche dessen Pfad für laufende Rebase-Vorgänge mit printConflictDetailsWithContinue. Verfolge anschließend git.RebaseContinue in internal/git/gitops.go und tryAutoResolveRebase in internal/git/git.go; reproduziere den Konfliktablauf über mehrere Commits mit gh stack rebase --continue. Als erledigt gilt die Aufgabe, wenn ein späterer Konflikt den aktuellen Block Conflicted files anstelle nur des generischen Fehlers meldet.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Summary
gh stack rebase --continue only prints Conflicted files: listing for first conflict encountered when cascading one stacked branch onto another. If resolving that conflict and continuing causes git to hit a second conflict on a later commit within the same branch's replay, the tool does not report what files are now conflicted and just returns a generic wrapped error.
This can make it look like there's only one conflicted file when there are actually more. You can only see the other conflicts by manually running git status.
Steps to reproduce
- Create a stack with a branch containing at least two commits and at least two files, where:
- Commit A modifies
file1.txtso that there's a conflict with the (rebased) parent branch. - Commit B later modifies
file2.txtso that it also conflicts with the parent branch, independently of commit A.
- Commit A modifies
- Rebase the stack
- The tool stops on commit A's conflict and correctly prints:
Conflicted files: C file1.tsx (lines N–M) - Resolve
file1.txt, stage it, rungh stack rebase --continueagain. - Git internally applies commit B next, which conflicts on
file2.txt.
Expected behavior
Step 5 should print the same kind of Conflicted files: block, listing file2.txt with its conflict line numbers, like step 3 did for file1.txt.
Actual behavior
Step 5 prints a generic error:
rebase continue failed — resolve remaining conflicts and try again: exit status 1
No indication of which file(s) are now conflicted. The only way to discover where the new conflict is is running git status manually.
Proposed solution / notes
I'll be honest, not familiar with Go so this "solution" is mostly Claude. I did double check that it looks at least mostly right to me. Figured it might be helpful.
Traced this to
cmd/rebase.goandinternal/git/git.go:
printConflictDetails()/printConflictDetailsWithContinue()(cmd/rebase.go:545) is the function that formats theConflicted files:block with per-file conflict-marker line numbers (viagit.FindConflictMarkers). It's only called from the branch-to-branch cascade logic, atcmd/rebase.go:259and:435.continueRebase()(cmd/rebase.go:312) has a separate path for resuming an already in-progressgit rebasewithin a single branch's multi-commit replay:This path never callsif git.IsRebaseInProgress() { rebaseOpts := git.RebaseOpts{CommitterDateIsAuthorDate: state.CommitterDateIsAuthorDate} if err := git.RebaseContinue(rebaseOpts); err != nil { return fmt.Errorf("rebase continue failed — resolve remaining conflicts and try again: %w", err) } }printConflictDetails.- Following
RebaseContinue(internal/git/gitops.go:334) intotryAutoResolveRebase(internal/git/git.go:118), the conflicted-files list is actually fetched — just to check whetherrererealready auto-resolved everything — and then discarded on the way out:conflicts, err := ConflictedFiles() if err != nil { return originalErr } if len(conflicts) > 0 { return originalErr // <-- conflicts is right here and gets thrown away }Fix: in
continueRebase, whengit.RebaseContinuereturns an error, callprintConflictDetailsWithContinue(using the still-in-progress rebase's current conflicted files, e.g. by callinggit.ConflictedFiles()again, or by threadingtryAutoResolveRebase's localconflictsslice out through the error) before returning, instead of just wrapping the raw error string. That gives resume-mid-branch conflicts the same reporting as cascade-boundary conflicts.
Environment
ghversion: 2.97.0 (2026-07-31)gh-stackextension:github/gh-stackv0.1.0- OS: macOS Tahoe 26.5.1
- 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 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
bazel-contrib/rules_go#4726 · 1 Kommentar ·
-
area/auto-scaling area/monitoring area/ops-productivity kind/enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
-
Type/Improvement
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 90/100
OpenNSW/nsw-srilanka#522 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 92/100