Well, Graphite solves the problem of how to keep your stack of GitHub pull requests in sync while you squash merge the lowest pull request in the stack; which as far as I know jujutsu does not help with.

▲

ninjha 3 days ago | parent | next [-]

jj-spr solves this, although it is still pretty buggy: https://github.com/LucioFranco/jj-spr

▲

samhh 3 days ago | parent [-]

There’s also jj-stack. I don’t know how they compare.

This is something GitHub should be investing time in, it’s so frustrating.

▲

paradox460 3 days ago | parent [-]

And tangled.sh supports JJ stacks out of the box

	▲	brw 2 days ago \| parent [-]
		Woah that's actually huge. I've been very interested in tangled from an atproto perspective but I had no idea it had that as well. Wonder why that isn't talked about more. Seems like an amazing feature to potentially pull some people away from GitHub/GitLab after they've have been asking for years for a better stacking workflow. I've been going through a lot of different git stacking tools recently and am currently quite liking git-branchless[1] with GitHub and mergify[2] for the merge queue, but it all definitely feels quite rough around the edges without first-party support. Especially when it comes to collaboration. Jujutsu has also always just seemed a bit daunting to me, but this might be the push I needed to finally give both jj and tangled a proper try and likely move stuff over. [1] https://github.com/arxanas/git-branchless [2] https://mergify.com

▲

aabhay 3 days ago | parent | prev [-]

jj is actually perfectly fit for this and many other problems. In fact, this is actually the default behavior for jj -- if you squash a bunch of jj commits, the bookmarks on top automatically point to the updated rev tree. Then when syncing the dependent branches to git they all rebase automatically.

The problem however lies in who or what does this rebasing in a multi-tenant environment. You sort of need a system that can do it automatically, or one that gives you control over the process. For example, jj can often get tripped up with branch rules in git since you might accidentally move a bookmark that isn't yours to move, so to speak.

▲

jacobegold 3 days ago | parent [-]

Correct (Graphite eng here for context) - we've thought about extending our CLI to allow it to sync jj with GH pull requests to do exactly this. Essentially - similar workflow but use `jj` as the frontend instead of `gt`

	▲	koreth1 2 days ago \| parent [-]
		Please do this! As a Graphite user, I'd love to be able to switch to jj for my local development, but the disconnect between it and Graphite keeps me away.