Stacked PR workflow for GitHub

[GreyTeardrop]

Hi! I've discovered JJ a couple of weeks ago and really love it.

Right now I'm adjusting my stacked PR workflow from Git (which used to be really painful) to JJ. It's mostly straightforward when it comes to creating/updating PRs, I'm only uncertain about the PR merge flow. Just to note, we tend to merge GitHub PRs via squashing or rebasing and our repos are usually configured to automatically delete remote branch when the PR is merged.

So, when the PR created from the branch some-feature is merged into main, I do this:

# avoid fetching everything in order not to pull some-feature@origin removal yet
jj git fetch --branch main
# rebase all descendants of some-feature onto updated main
jj rebase -s "all:some-feature+" -d main
# abandon already merged commits
jj abandon "main..some-feature"
# fetch everything, including the removal of some-feature@origin
jj git fetch
# delete the bookmark - it gets into conflicted state and isn't deleted automatically
jj bookmark delete some-feature

This is already a enormous upgrade compared to Git with its manual git rebase --ontos for every child PR. I wonder if JJ workflow can somehow be improved even further?

[joyously]

Didn't the rebase already happen on the remote?

[GreyTeardrop]

Yep, those are the commands I run after the merge happens on the remote.
Sorry, I misunderstood the question initially. Remote does rebase some-feature onto main, I'm rebasing any child PRs stacked on top of some-feature.

[jennings]

I think your first step should be jj git fetch, without limiting it to main. When you do, the following will happen:

• Your local bookmark some-feature will be deleted
• Your local commits that were previously in main..some-feature will automatically be abandoned (if they became unreachable on the remote)

Then, rebase your remaining commits onto main.

• If they became conflicted in the previous step (due to the unreachable commits being abandoned), the conflicts will likely disappear.
• If the commits didn't get abandoned in the previous step because they're still reachable, this will probably abandon them because they became empty.

[GreyTeardrop]

I tried something like that the first time I merged one of my stacked PRs but probably did something wrong, as the when I did jj git fetch the some-feature bookmark got removed but all its commits stayed, so I had to manually locate a commit the bookmark was on to rebase its ancestor commits. Not sure if that's due to the way GitHub works (as even after the PR branch gets removed and PR merged, one could always check PR commits via web UI so perhaps those never become unreachable?), or maybe I just messed something in my setup.

[jennings]

When a branch is deleted from the remote, jj abandons the commits from that branch if:

• Those commits are now unreachable from any remote branch
• You haven’t disabled this behavior with config

My guess is that there was another remote branch that still had a reference to those commits.

In that situation, you likely want to rebase onto main, which will either abandon those commits that become empty, or become conflicted but you can just abandon them anyway.

[GreyTeardrop]

I see. You're right, there were some PRs stacked on top of the merged one, so branches of those yet-unmerged PRs included all the commits from the merged ones. I'm trying to rebase those onto master - but I can only do that after the initial PR was merged and new commits added to the main branch.