this is an unambitious implementation of stacked PRs. GitHub’s stacked PRs build entirely on the existing, flawed model of GitHub PRs without changing any of the foundations
The feature people've been waiting years for comes out and is entirely lacklustre.
Wonderful article from a real power user with lots to share. This is a real streamlined flow.
I think it really shows the impractical edges on gh stack as well. Even trying to use this on the blessed path I found it pretty awkward to use. I have all my git tools and suddenly I need to stop using them and to back to calling out to a special version of every command.
The limitation on reordering a stack was a surprise to me. If you do that, I presume you lose all of your reviews after that point too?
Wonderful article from a real power user with lots to share.
Thanks!
The limitation on reordering a stack was a surprise to me. If you do that, I presume you lose all of your reviews after that point too?
I haven't tested exactly that, but I think GitHub only closes the PR if the branch is deleted. So if you delete the stack (which doesn't delete the PRs), re-order your commits/branches locally, jj git push ..., gh stack link ..., it should link a new stack with all the original PRs in the new order. gh stack link discovers existing PRs for a branch, which makes that all work. I think.
EDIT: I did test inserting a commit in the middle of the stack, which is a kind of reordering, and as long as you don't push the branch deletes it works fine (as in, none of the PRs will be closed or deleted).
Very useful tips, thanks for sharing. One improvement to the workflow could be to use jj git push --change <revset>, optionally with a git_push_bookmark template defined in your jj config, to avoid needing to manually edit each change and create the bookmark. I’ve got my template set up to convert the first ~60 characters of the commit message to a branch name with a regex. Given that you can also pass a revset to the --change argument, you could create bookmarks and push them for the whole stack in one command.
Honest question -- why do all this? The fundamental building blocks of jj directly, easily support stacks without any customization. You can move to any point in a stack of commits, add more work at any point, label each point in the stack with a bookmark, all with built-in commands.
I too went through a phase of "revset alias everything", but jj has such powerful primitives that I find this kind of customization to be counter-productive.
I've been using GitHub Stacks with jj for the last few weeks and this article would have been very helpful when I was first figuring things out!
One thing I do differently than the workflow here is use jj-gh to create the PRs, rather than letting gh stack link do the job. That tool gives you more control over what the PR title and description look like. I found that PRs created using gh stack link would often end up with a title that was just my bookmark name, and I'd have to go manually copy-paste my commit messages into the PR. I still run gh stack link to tell GitHub about the stack, but it detects that there are existing PRs and links those PRs together rather than creating new ones.
alper | 5 hours ago
The feature people've been waiting years for comes out and is entirely lacklustre.
dominicm | 13 hours ago
Wonderful article from a real power user with lots to share. This is a real streamlined flow.
I think it really shows the impractical edges on gh stack as well. Even trying to use this on the blessed path I found it pretty awkward to use. I have all my git tools and suddenly I need to stop using them and to back to calling out to a special version of every command.
The limitation on reordering a stack was a surprise to me. If you do that, I presume you lose all of your reviews after that point too?
[OP] altano | 11 hours ago
Thanks!
I haven't tested exactly that, but I think GitHub only closes the PR if the branch is deleted. So if you delete the stack (which doesn't delete the PRs), re-order your commits/branches locally,
jj git push ...,gh stack link ..., it should link a new stack with all the original PRs in the new order.gh stack linkdiscovers existing PRs for a branch, which makes that all work. I think.EDIT: I did test inserting a commit in the middle of the stack, which is a kind of reordering, and as long as you don't push the branch deletes it works fine (as in, none of the PRs will be closed or deleted).
bengesoff | 5 hours ago
Very useful tips, thanks for sharing. One improvement to the workflow could be to use
jj git push --change <revset>, optionally with agit_push_bookmarktemplate defined in your jj config, to avoid needing to manually edit each change and create the bookmark. I’ve got my template set up to convert the first ~60 characters of the commit message to a branch name with a regex. Given that you can also pass a revset to the--changeargument, you could create bookmarks and push them for the whole stack in one command.restrictedchoice | 2 hours ago
Honest question -- why do all this? The fundamental building blocks of
jjdirectly, easily support stacks without any customization. You can move to any point in a stack of commits, add more work at any point, label each point in the stack with a bookmark, all with built-in commands.I too went through a phase of "revset alias everything", but
jjhas such powerful primitives that I find this kind of customization to be counter-productive.koreth | 3 hours ago
I've been using GitHub Stacks with jj for the last few weeks and this article would have been very helpful when I was first figuring things out!
One thing I do differently than the workflow here is use jj-gh to create the PRs, rather than letting
gh stack linkdo the job. That tool gives you more control over what the PR title and description look like. I found that PRs created usinggh stack linkwould often end up with a title that was just my bookmark name, and I'd have to go manually copy-paste my commit messages into the PR. I still rungh stack linkto tell GitHub about the stack, but it detects that there are existing PRs and links those PRs together rather than creating new ones.