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.
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.
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`
ninjha|2 months ago
samhh|2 months ago
This is something GitHub should be investing time in, it’s so frustrating.
aabhay|2 months ago
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|2 months ago