Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

submit marks existing draft PRs ready for review without --open, firing review requests

Open
#481 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
58/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
github, go
Domain
api, cli

Research direction

Start by running the reported two-pass gh stack submit --auto reproduction and inspect the submit command's update path, especially where existing pull requests are handled. Compare that path with the --open behavior and verify with gh pr view A --json isDraft; done means repeat submissions leave existing drafts unchanged unless --open is passed, with tests covering the regression.

Written by the indexing model from the issue text.

Description

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 --open to 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.

Dominant language
Go
Stars
1.5k
Forks
73
Avg merge
1d 8h
Merged PRs (30d)
7

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/gh-stack

All issues in github/gh-stack

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.