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.
In terms relevant for this thread, jujutsu is a git CLI with much better UX and support for change IDs. Most history editing operations become trivial. Code review and PR management should be a much thinner layer if implemented on top of jujutsu.
Personally, I think jujutsu has already succeeded at becoming a "git killer" in terms of UX and adoption. It is compatible with git, so I'm never going back to using git directly.
1. It's explained in the README [1]. Tl;dr: Maiao is a "remote, sparsely populated volcanic atoll in French Polynesia"
2. I don't think so. The main difference from maiao to other stacked diffs projects is that it _progressively enhances_ GitHub. At the end of the day you just get PRs with branch #3 -> branch #2 -> branch #1 -> main. So, a bit of automation and rebases to do this. Because teams rarely can choose their forge, the intent is to not force org-wide change — e.g., change the VCS to jj — nor introduce more API/UI surface. You can be the only one doing stacked diffs in your team. Nothing breaks.
jj can work with git as its storage, so all of its commits are git commits, so a jj-local and git-remote flow is fully supported. I use it, and as far as I know I'm the only one on my team doing so.
Comments
Is it compatible with jujutsu?
I'm not familiar with jujutsu. Maiao is fully git-compatible and the idea is to
a) Not create new API/commands on top of it. Everything works with the normal "git commit".
b) Progressively enhance the user experience. Each commit becomes a PR stacked atop each other. It auto-rebases if the base changes, and so on.
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.
In terms relevant for this thread, jujutsu is a git CLI with much better UX and support for change IDs. Most history editing operations become trivial. Code review and PR management should be a much thinner layer if implemented on top of jujutsu.
Personally, I think jujutsu has already succeeded at becoming a "git killer" in terms of UX and adoption. It is compatible with git, so I'm never going back to using git directly.
jj is a pretty nifty VCS - certainly worth looking in to. A lot of the concepts run parallel to Maiao I _think_, I'm still learning jujitsu myself.
A couple questions:
1) what's the name about? 2) does this get wicked messy if I'm the only one on my team using Maiao?
1. It's explained in the README [1]. Tl;dr: Maiao is a "remote, sparsely populated volcanic atoll in French Polynesia"
2. I don't think so. The main difference from maiao to other stacked diffs projects is that it _progressively enhances_ GitHub. At the end of the day you just get PRs with branch #3 -> branch #2 -> branch #1 -> main. So, a bit of automation and rebases to do this. Because teams rarely can choose their forge, the intent is to not force org-wide change — e.g., change the VCS to jj — nor introduce more API/UI surface. You can be the only one doing stacked diffs in your team. Nothing breaks.
1 - https://github.com/runetes/maiao/#why-maiao
jj can work with git as its storage, so all of its commits are git commits, so a jj-local and git-remote flow is fully supported. I use it, and as far as I know I'm the only one on my team doing so.
Thanks! Sorry about 1, I was worried I had missed it in the readme, I was hopping all over the docs pages before coming back to the post lol
Very cool stuff, will be trying it out
jj support doesn't force an org-wide change. jj is compatible with git. It's just that the mental model is more aligned to Gerrit and stacked PRs.
Probably worth looking into. It provides most of the machinery here on the version control side.