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 sync operation. If it would not significantly impact performance, then we can prompt the user as above.
If a PR happens to be closed, but is still tracked, updating the PR will result in an error akin to:
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
--yesflag as provided tosubmit. TheREADME.mdshould be updated with a warning (> [!WARNING]) about destructive operations that can occur if the--yesflag 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 submitoperation, they must be skipped. We do not need to notify the user that the branches have been skipped.Bonus points:
gh stack syncoperation. If it would not significantly impact performance, then we can prompt the user as above.