submit: handle closed/merged PRs
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 48/100
Research direction
Start with the gh stack submit and gh stack sync entry points, then inspect the existing gh stack orphan --force behavior and README.md warning guidance. Done means closed PRs are detected during submit, confirmation and --yes behavior handles affected stacked branches and skips them, README.md documents the destructive --yes warning, and sync feasibility is assessed.
Written by the indexing model from the issue text.
Description
If a PR happens to be closed, but is still tracked, updating the PR will result in an error akin to:
Updating PR #1234 for some-branch (base: trunk-branch)... failed
! failed to update PR #1234 base: failed to update PR #1234 base: HTTP 422: Validation Failed (https://api.github.com/repos/some/repo/pulls/1234)
PullRequest.base is invalid
My ideal solution is to detect closed PRs and prompt the user to orphan the branch. However, if this branch is in the middle of a stack, orphaning the branch would cause the rest of the branches behind it to also be orphaned (this is the behavior of gh stack orphan --force). In that case, the prompt message should note this and list the branches that will also be orphaned.
This feature will respect the --yes flag as provided to submit. The README.md should be updated with a warning (> [!WARNING]) about destructive operations that can occur if the --yes flag is provided.
If the user confirms that the branch(es) should be orphaned, then they are immediately orphaned. If those branches would have otherwise been updated in remainder of the gh stack submit operation, they must be skipped. We do not need to notify the user that the branches have been skipped.
Bonus points:
- Investigate feasibility of detecting closed (but unmerged) PRs on a
gh stack syncoperation. If it would not significantly impact performance, then we can prompt the user as above.
- Dominant language
- Go
- Stars
- 9
- Forks
- 2
- Avg merge
- 15h 9m
- Merged PRs (30d)
- 4
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from boneskull/gh-stack
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 25/100
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
performance
Difficulty 5/5 Over a week Newbie friendliness 35/100
All issues in boneskull/gh-stack
Similar issues
-
Difficulty 1/5 1-3 hours Newbie friendliness 90/100
FootprintAI/Containarium#2338 ·
Maintainers usually reply within 1 day
-
[Bug]: core doesn't build standalone on dev since a17068054 (go-mp3 require dropped, go.sum pruned)Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
SagerNet/sing-openvpn#11 ·
-
priority: P3 type: devops
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
jiegui2025/hwspec#57 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
columnar-tech/dbc#513 ·
Maintainers usually reply within 1 day