Jujutsu has a mental model that aligns far more closely to Gerrit than GitHub etc.
It uses a persistent changeid to model a change mutating over time, like Gerrit uses Change-Id in the description footer, and unlike git.
Jujutsu can be colocated with git and use .git as its backing store; every jj change revision is a git commit.
When you use jujutsu, you tend not to use branches any more, and think in terms of changes and chains of changes (i.e. stacked PRs, what Gerrit calls Relation Chains).
Jujutsu makes it very easy to work with a chain of changes (stacked PRs), letting you update commits in the middle and automatically rebasing the rest of the chain, without forcing you to interrupt work and resolve conflicts if there happen to be any (so, unlike git rebase -i with 'edit' on the commit you want to update).
IMO if you like the Gerrit workflow and the way it handles chained commits, if you switch to jj for two days of work, you'll never want to use git again.
I should probably post my guide on how to use gerrit and JJ together nicely.
I wrote it internally after struggling a lot with getting the relevant knowledge from the relevant authorities (Klabnik has the best resources but his writing seems to depend on you understanding abstract concepts before you grasp the practicality, which works for programming languages but less so for tools - which you want to "get out of the way").
I agree. Mutable commits are making a comeback recently and I love it. A hill I'll also die on is that branches shouldn't exist lol. Disclaimer - I'm the founder - but if you want a review tool that caters to jj users you might like revset.dev. It shows you the jj commits that make up a PR, and you can see the various revisions the jj commits and PR have gone through
It does. This is definitely something that's being actively iterated on though. Let's say as a reviewer you leave some comments on Revision 3, then the user pushes 2 more PR revisions and asks you to re-review. The default diff when you open the PR again will be from Revision 3 -> Current code. It lets reviewers easily see what's changed since their last review.
There are also the "Mark as reviewed" checkboxes per file that can help you track what's been looked at.
Comments
Jujutsu has a mental model that aligns far more closely to Gerrit than GitHub etc.
It uses a persistent changeid to model a change mutating over time, like Gerrit uses Change-Id in the description footer, and unlike git.
Jujutsu can be colocated with git and use .git as its backing store; every jj change revision is a git commit.
When you use jujutsu, you tend not to use branches any more, and think in terms of changes and chains of changes (i.e. stacked PRs, what Gerrit calls Relation Chains).
Jujutsu makes it very easy to work with a chain of changes (stacked PRs), letting you update commits in the middle and automatically rebasing the rest of the chain, without forcing you to interrupt work and resolve conflicts if there happen to be any (so, unlike git rebase -i with 'edit' on the commit you want to update).
IMO if you like the Gerrit workflow and the way it handles chained commits, if you switch to jj for two days of work, you'll never want to use git again.
I should probably post my guide on how to use gerrit and JJ together nicely.
I wrote it internally after struggling a lot with getting the relevant knowledge from the relevant authorities (Klabnik has the best resources but his writing seems to depend on you understanding abstract concepts before you grasp the practicality, which works for programming languages but less so for tools - which you want to "get out of the way").
in fact.. screw it... here: https://blog.dijit.sh/gerrit_with_jj/
I agree. Mutable commits are making a comeback recently and I love it. A hill I'll also die on is that branches shouldn't exist lol. Disclaimer - I'm the founder - but if you want a review tool that caters to jj users you might like revset.dev. It shows you the jj commits that make up a PR, and you can see the various revisions the jj commits and PR have gone through
Does it let you manually keep track of the parts you've actually seen? Instead of using the granularity provided by the PR author?
It does. This is definitely something that's being actively iterated on though. Let's say as a reviewer you leave some comments on Revision 3, then the user pushes 2 more PR revisions and asks you to re-review. The default diff when you open the PR again will be from Revision 3 -> Current code. It lets reviewers easily see what's changed since their last review.
There are also the "Mark as reviewed" checkboxes per file that can help you track what's been looked at.