You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm wondering if there is a way to update draft PRs with this tool. Let's say I have a stack of 3 commits and run stack-pr submit --draft. It will create 3 local branches and 3 draft PR's. If I then make some changes to those three commits and run stack-pr submit --draft, I now see it creates 3 new local branches (total 6 now) and 3 new draft PRs (total 6 now). From the README, it seems like the second submit command should update the existing PR's. How do I ensure stack-pr keeps local branch to PR mapping for draft PR's? I'm also wondering why new branches get created on the second submit command?
Another piece of feedback is that if the above scenario happens and the user ends up with duplicate commits in the stack/branches, the user experience is very disorienting.
Hi! That doesnt sound like a correct behavior, so you might be hitting a bug there. Do you mind pasting exact commands that you use that result in this? FWIW, you shouldn't see any new local branches after stack-pr submit - it's supposed to clean them up - so maybe it hits some error in the process.
Thanks @ZolotukhinM! I can give a rough overview of what happened to see if you can repro. It could be that I am not using the correct workflow in the stack-pr model.
I had a local feature branch with 9 commits, let's call it feat_123
I ran the stack-pr submit --draft which created 9 local branches with names natmod/stack/1 through natmod/stack/9 as well as the remote branches and draft PR's with dependencies as expected.
I then ran a linter through each commit in the stack, by doing git rebase -i main --> edit each commit --> run linter --> git commit --amend + git rebase --continue
I then ran stack-pr submit --draft thinking this would update the branches and PRs for natmod/stack/1 through natmod/stack/9, but instead it created 9 new local/remote branches and 9 new PRs (natmod/stack/10-natmod/stack/18).
I'm wondering if the issue is that I am using interactive rebase and if stack-pr intends for users to use a different workflow? My ideal experience is that I could do anything in interactive rebase like squash, skip, or reorder commits and stack-pr would intelligently handle the branching and PR dependencies with minimal changes.
Interactive rebase is the intended way to update a stack, so something odd is happening. I do have a question about the way you amended the commits in the stack: did you change the commit message? stack-pr appends a stack-info line to PRs to store the remote branch and PR for each commit, and if that goes missing it will not be able to find the previous artifacts.
+1 to @AmaranthineCodices, if you accidentally removed the new lines from the commit messages then it would've indeed resulted in creating new PRs and branches. These lines are used to associate a commit with an existing PR.
Another odd thing is that you see natmod/stack/* branches. The tool is supposed to remove them when it succeeds (it does create them as it prepares the PRs and they do exist on the remote, but locally you shouldn't see them). Did it error out or got interrupted at any point?
Activity
ZolotukhinM commentedon Feb 5, 2025
Hi! That doesnt sound like a correct behavior, so you might be hitting a bug there. Do you mind pasting exact commands that you use that result in this? FWIW, you shouldn't see any new local branches after
stack-pr submit- it's supposed to clean them up - so maybe it hits some error in the process.natmod commentedon Feb 5, 2025
Thanks @ZolotukhinM! I can give a rough overview of what happened to see if you can repro. It could be that I am not using the correct workflow in the stack-pr model.
I had a local feature branch with 9 commits, let's call it
feat_123I ran the
stack-pr submit --draftwhich created 9 local branches with namesnatmod/stack/1throughnatmod/stack/9as well as the remote branches and draft PR's with dependencies as expected.I then ran a linter through each commit in the stack, by doing
git rebase -i main--> edit each commit --> run linter -->git commit --amend+git rebase --continueI then ran
stack-pr submit --draftthinking this would update the branches and PRs fornatmod/stack/1throughnatmod/stack/9, but instead it created 9 new local/remote branches and 9 new PRs (natmod/stack/10-natmod/stack/18).I'm wondering if the issue is that I am using interactive rebase and if
stack-printends for users to use a different workflow? My ideal experience is that I could do anything in interactive rebase like squash, skip, or reorder commits andstack-prwould intelligently handle the branching and PR dependencies with minimal changes.AmaranthineCodices commentedon Feb 13, 2025
Interactive rebase is the intended way to update a stack, so something odd is happening. I do have a question about the way you amended the commits in the stack: did you change the commit message?
stack-prappends astack-infoline to PRs to store the remote branch and PR for each commit, and if that goes missing it will not be able to find the previous artifacts.ZolotukhinM commentedon Feb 14, 2025
+1 to @AmaranthineCodices, if you accidentally removed the new lines from the commit messages then it would've indeed resulted in creating new PRs and branches. These lines are used to associate a commit with an existing PR.
Another odd thing is that you see
natmod/stack/*branches. The tool is supposed to remove them when it succeeds (it does create them as it prepares the PRs and they do exist on the remote, but locally you shouldn't see them). Did it error out or got interrupted at any point?