[hxtk]

GitLab is actively developing native support for stacked diff workflows. CLI support for creating stacks landed in GitLab 17, and now they’re working on the code review workflow for it.

To be honest, though, I find it easiest to create several branches with Jujutsu and then manually chain the MRs. That’s what glab does under the hood with glab stack commands. Looking forward to the code review tools in a future version.

For GitHub, though, I think Graphite is the best tool I’ve looked at so far, but I use GitLab at work so I’m not the best judge of GitHub tools for lack of experience using them at scale.

[cmrdporcupine]

Putting stacked diffs aside, I'd frankly just be happy with the ability to track comments across different commit hashes. This is something neither GitLab or GitHub can do:

1. "Please change this" 2. <I change it, and force-push the change [cuz I don't like a messy git history]> 3. Comment keeps association with the original line and/or its new replacement.

Gerrit has no problem w/ this flow. GH and GL both can't do it.

GH wants to force you to put a pile of "fix" commits in and then either do a merge commit (eww) or squash the whole thing into one commit (not ideal in some cases).

[angus-g]

How does Gerrit manage this? Are the comments associated with the source content, instead of commits?

[naiquevin]

Gerrit uses a “Change-Id” trailer with a unique value. When you “fix up” a commit, the commit SHA changes but the change id remains the same. That’s how it can identify different commits with the same change id as patchsets of the same change.

This is based on what I remember (haven’t used gerrit in a while), so it may not be accurate.

I used gerrit in my previous job and miss using it. Would definitely prefer it over GitHub which is more popular (and convenient of course, can’t deny that).

[hxtk]

Your understanding of the Change-Id footer sounds like it matches mine.

I’d note that it works that way presently, but the teams behind git, gerrit, jj-vcs, and a couple of other relevant stakeholders have an email thread going in which, from what I understand, they discuss standardizing on the approach taken by jj-vcs:

https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf...

[phatskat]

I’ve really enjoyed jj and im happy to see the community working together on these kinds of things.