submit marks existing draft PRs ready for review without --open, firing review requests
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 58/100
Rechercherichtung
Beginne damit, die gemeldete Reproduktion mit zwei Durchläufen von gh stack submit --auto auszuführen, und untersuche den Aktualisierungspfad des Befehls submit, insbesondere die Stelle, an der vorhandene Pull Requests behandelt werden. Vergleiche diesen Pfad mit dem Verhalten von --open und überprüfe dies mit gh pr view A --json isDraft; erledigt ist die Aufgabe, wenn wiederholte Übermittlungen vorhandene Entwürfe unverändert lassen, sofern nicht --open übergeben wird, und Tests die Regression abdecken.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Environment
- gh 2.96.0 (2026-07-02), gh-stack v0.0.4, git 2.46.1, macOS 26.6
Summary
gh stack submit --auto marked two already-open draft PRs as ready for review, which fired review requests to five CODEOWNERS. I did not pass --open.
The help text is explicit that this should not happen:
New PRs are created as drafts by default. Use
--opento mark them as ready for review.
Repro
gh stack submit --auto # creates PR A and PR B as drafts
gh pr view A --json isDraft # => true, as documented
# ... make no change to the branches ...
gh stack submit --auto # second run, still no --open
gh pr view A --json isDraft # => false
Second run's output, which gives no indication it changed draft state:
Checking stack state...
Pushing to origin...
PR #A for branch-a is up to date
PR #B for branch-b is up to date
✓ Stack updated on GitHub with 2 PRs
✓ Pushed and synced 2 branches
The PR timeline confirms it:
<t> ready_for_review by=<me>
<t> review_requested by=<me> x5
Those timestamps match the second submit to the second. I made no other change in between, and did not touch the web UI.
Why it matters
Marking a PR ready is not a local operation. It notifies every CODEOWNER, and on a repo with required reviewers it moves the PR into other people's queues. Doing it on an update pass, from a flag whose documented meaning is "use auto-generated titles without prompting", is surprising in a way that cannot be undone: gh pr ready --undo restores draft state but the notifications have already gone out.
It also makes submit unusable as an idempotent "sync my stack" command, which is what its output implies it is when everything is already up to date.
Expected
submit should only change draft state when --open is passed. If the current behaviour is deliberate for update passes, the help text should say so, and the output should name the change instead of printing is up to date.
- Vorherrschende Sprache
- Go
- Sterne
- 1.5k
- Forks
- 73
- Ø Merge
- 1 T. 8 Std.
- Gemergte PRs (30 T.)
- 7
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
-
textual definition
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
geneontology/go-ontology#32653 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 75/100
-
needs design
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Priority/High ready-for-agent Severity/Major Type/Bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100