Github and GitLab both allow you to specify a merge target other than main and only show you the differences from the target. If that target is merged into main, they're retargeted to main.

There is definitely room for an improved forge experience that takes advantage of the additional powers of jj, but it's no worse an experience using them today than it is with git.

▲

nothrabannosir 3 days ago | parent | next [-]

By any chance did you manage to get branch protection rules working neatly in this paradigm? Ideally I’d like any CI to be re-run as necessary and the branch to be automatically merged if review was approved and its base became master, but I never got a completely hands free setup working. Maybe a skill issue though.

Basically if I have five stacked PRs, and the newest four get an approval, I want everything to stay in place no merges. Then when the base (oldest) PR gets approved, I’d like the PRs to all get merged, separately , one after the other, without further interaction from me.

Does GitHub’s merge queue implementation support that?

	▲	stouset 3 days ago \| parent [-]
		Gitlab’s does when you have merge queues set up. I’m not sure about GitHub, we didn’t have that kind of setup at the last place I worked.

▲

diarrhea 3 days ago | parent | prev [-]

One problem remains: jj makes it a breeze to parallelize work, but descendant changes will then end up with multiple parents. But PRs cannot target multiple target branches at once - so you cannot point them at both at once.

cf. https://jj-vcs.github.io/jj/latest/cli-reference/#jj-paralle...

	▲	sgjennings 3 days ago \| parent [-]
		I mostly solve this by putting a branch on the merge commit M, then the “real” change R is a child of that. The PR is targeted to merge R into M. As the parents of M are merged, I rebase the whole stack. When M has a single parent left, I abandon M and retarget the PR to merge R into that parent. It requires a little babysitting, but the PR shows the diff I want it to.