Repository navigation
Sync before submit when a PR in the stack has merged - #62
Merged
Merged
Conversation
Running git ss after the PR below had merged (but before a sync) pushed the branch as it was: gh stack skipped the merged branch and based the new PR on main, so it showed the merged commits as well as its own, and our result claimed we'd "created" the merged PR too. The merged flag in the metadata is only ever set by gh stack, so submit didn't know; the fresh PR list it fetches anyway did. So submit now treats a branch as merged when the forge says so, and when any branch of the stack has merged it runs the normal sync first (merged branch deleted, the ones above restacked onto trunk) and carries on from the stack as it is afterwards. If the merged branch was the one checked out, a whole stack submit picks up from whatever is left; a --down submit to it has nothing to do and says so. The sync is in the result (and shown by the CLI), and a dry run just names the branches and leaves them out of the plan.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hit this on the monorepo today: I created a branch on top of one whose PR had just merged, ran
git sswithout syncing first, and got a new PR with both commits in it. gh stack saw the merged PR, skipped that branch and based the new PR on main, but the local branch was still sitting on the merged branch's commit so the diff showed both. Our own result then listed the merged PR as "created" as well, which it wasn't.The cause is that submit only knew a branch was merged from the
mergedflag in gh stack's metadata file, and gh stack is the only thing that sets that (during its own submit, i.e. too late). The fresh PR list submit fetches anyway already said the PR had merged, we just weren't looking at it.So submit now reads merged from the forge too, and when any branch of the stack has merged it runs the normal sync before pushing anything: the merged branch is deleted, the ones above are restacked onto trunk, and the submit carries on from the stack as it is afterwards. If you were on the merged branch itself, a whole stack submit picks up from whatever is left (sync has moved you to trunk);
git ss --downon it has nothing to do and says so. What the sync did is in the result and the CLI prints it above the submit lines; a dry run can't sync so it just names the branches and leaves them out of the plan. A merged branch that sync keeps (prune set to never, a dirty checkout) is skipped the way gh stack skips it, same as before.