GitHub Stacks in Jujutsu
36 points by altano
36 points by altano
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.
The devex for managing your stack is definitely lackluster, but I think the experience of a reviewer reviewing your stack is good, and that’s the most important thing.
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).
I've been using GitHub Stacked PRs 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.
Honest question -- why do all of 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.
All but one of the revset aliases are there to either:
Neither of these are built-in.
For the vast majority of use cases, where the stacks start on main (or whatever your trunk() is) and you're anywhere in the stack, and each PR in the stack has a bookmark, running jj log with the default revset shows the whole stack. Then, jj new jumps to any point in the stack. What am I missing?
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.
Whattttt, git_push_bookmark is a great tip. I will work it into the article as soon as I have some time. Thanks!