[cmrdporcupine]

Side note: I really miss Gerritt from my time working at GOOG, but man is its deployment story kinda crap in the 2020s. I tried to run an instance locally and was hoping to integrate it with my github hosted repo ended up just frustrated.

Is there anything equivalent -- that handles tracking changes over commits etc better than GH -- that is more actively developed and friendly for integration with GH? I hate GH's code review tools with the heat of 10,000 suns.

[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.

[ezst]

I think phabricator was doing a decent job at it while it lasted, don't know where they are at since IIRC it got abandoned and then forked.

The best way to track meta history is to have it baked into the VCS, so here Mercurial is king, and heptapod (a friendly fork of Gitlab meant to support Mercurial repos and concepts) apparently does a good job at it since it's used for Mercurial's own development (after they transitioned from mailing lists to Gerrit? to phabricator to Heptapod)