[vlovich123]

And do downstream PRs show just what changed or is the merge target against main which then just keeps accumulating differences?

This is one of the strengths I appreciate about graphite which is that the PRs are always on the preceding branch but it knows that when you go to merge it should actually really retarget and merge against main.

[jacobegold]

(Graphite dev here)

Yeah – the key thing here is that there is work to be done on the server, so JJ likely either needs its own forge or a GitHub App that handles managing PRs for each JJ commit.

I'm a huge fan of the JJ paradigm – this is something I'd love for us to be able to do in the future once one or both of: - we have more bandwidth to go down this road - JJ is popular enough that its worthwhile for us to do

That said I'd also love to see if anyone in the community comes up with an elegant GH app for this!!

[koreth1]

As a satisfied customer of yours, the prospect of having to give up Graphite is the main thing keeping me from giving jj a try at my day job.

Ironic, since if there are a bunch of people in my boat, the lack of us in jj's user base will make it that much harder for jj to cross the "popular enough to be worth supporting" threshold.

[jacobegold]

My ideal is really just a version of `gt sync` and `gt submit` that handle updating the Graphite + Github server-side of things let you use `jj` for everything else, I think it could feel super nice. Probably not as simple as my dreams, but hopefully something we can get to with enough interest!

[stouset]

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]

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]

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]

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]

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.

[shayief]

Gitpatch author here.

Gitpatch attempts to build a Git hosting with native support for patches and commit-based review system, where each commit is its own patch. It's also smart to handle force pushes and can update or reorder patches as needed.

[jcgl]

Gitpatch looks really great. And I greatly appreciate you listing out alternatives.

Do you have any plans to allow for self-hosting?

[shayief]

thanks for checking it out.

yeah, I plan to release it under AGPL at some point when it’s more complete. Currently it still needs more work. But no timeline yet.