I’ve started using Jujutsu recently and was surprised at how low friction it was to switch. If you’re like the author and keep hearing about it without giving it a shot, I suggest you just sit down and try it – it’s a lot less effort than you might expect.
From git's perspective, jj bookmarks are just regular git branches, so you can just do `jj git push` and open a PR as usual.
However, unlike git, jj bookmarks are pinned to change IDs instead of immutable commit SHA-1s. This means that stacked PRs just work: Change something in the pr-1 bookmark, and all dependent bookmarks (pr-2, pr-3, ...) are automatically updated. A `jj git push --tracked` later and everything is pushed.
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.
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.
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!!
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.
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?
I started using jujutsu after the last round of blog posts here, and have found it super super useful to my mental model of git and vcs.
Stealing Fintan's `jj tug` alias from this post is something I have already found useful. Highly recommend if anyone is on the edge of trying to just give it a shot!
I feel like submodules are one of Git's most misused features. They're intended as a method of pinning read-only upstream Git dependencies. And when used for that purpose, they're good at what they do.
I think that people mostly get a bad taste in their mouths because they try to use submodules for building multi-repo workspaces where a developer might need to commit in some/all of the repos. They're a bad fit for that problem, but it's mostly because that's not what they were designed to do.
I'd love to see the jj team tackle case #2, personally. I bet they'd do a pretty good job of it.
I tried Jujutsu on a simple repo and it ended up a mess I couldn't fix. Never had that with git. Might be my lack of knowledge but it shouldn't allow this.
Yup. Still 0 incentive to try jj. I’m still very much convinced most of the problems solved by jj either do not exist or are already solved by recent features of git.
It’s good alternatives of popular tools exist but git would not be my first bet as a tool that needs fixing…
To be fair, I more or less invited these responses by bringing it up. Organically, complaints are very rare.
Obviously not everyone who tries something is going to switch, even if you take as an axiom that the other thing is objectively better. But I still think it’s notable that—without explicitly promoting that type of response—so few people seem to have negative experiences with jj given how tribal and passionate engineers tend to be over tooling.
And some people just happen to disagree - doesn't automatically mean they just like "being contrarian". I took the "Yup..." to mean "this is what I was expecting, because it agrees with what I have seen before on this topic".
> I always enjoy how on jj articles, 90% of commenters tried it and switched, 10% never bothered to try it, and 0% tried it but decided not to switch.
And some unknown quantity of readers don't see anything compelling enough to either try it and/or comment on it after they have (or have not) tried it.
I dunno, I've tried it and I think I will stick with Git for a while longer at least. I really don't like the fact that it automatically commits changes in the working tree. Apparently you can turn it off but.. yeah I dunno.
I may change my mind. Especially if they provide a less shit alternative to submodules and LFS. (And I agree this guy is just being contrarian - jj definitely does fix some Git annoyances.)
This was the thing that stopped me from giving jj a shot for the longest time, but it turned out to be a complete non-issue. Definitely don't turn it off!
The "aha" moment you might be missing is that you should consider your latest revision to just be the staging area. `jj commit -i` (shorthand for `jj describe; jj split -i`) is effectively `git add -i; git commit`. If you're worried about accidentally pushing unfinished work, don't be! It won't let you push changes without a message by default, and you update bookmarks (e.g., branch pointers) at your discretion anyway. Both of these mean that `jj git push` isn't going to accidentally push a bunch of in-flight work.
Think of it less like jj commits everything by default, and more like your working copy gets the benefits of change tracking and being able to take part in repo operations even when you haven’t taken a moment to make a commit.
You're reading an extremely biased sample of experiences. It's probably the opposite: 90% haven't tried it, 9% tried and didn't see any reason to switch, and around 1% have switched and won't shut up about it. For an advanced git user, it doesn't offer all that much. I used it for a couple of weeks and can't say that it saved me any time or any amount of work; it was either zero, or so close to zero that I wasn't able to notice it.
When Linus and his lieutenants switch over and recommend it as loudly as some do here, then I'll take another look. Very unlikely IMHO.
> For an advanced git user, it doesn't offer all that much.
As a (former) advanced git user, nothing could be further from the truth. We are always the most passionate cohort of jj users in these threads. This is almost certainly because jj unlocks a bunch of additional abilities and workflows that we've been torturing out of git (or given up on, or didn't even conceive was possible) for years.
On the flip side if all you ever do it git pull, git commit, git push, jj is probably not going to offer you much.
>For an advanced git user, it doesn't offer all that much.
arrogant, and completely absurdly wrong. I've used Git for 20 years. `jj` the single best improvement to my development workflow in... well, since adopting Git.
> I used it for a couple of weeks and can't say that it saved me any time or any amount of work
I would bet 5 figures that's a lie.
> When Linus and his lieutenants switch over and recommend it as loudly as some do here, then I'll take another look. Very unlikely IMHO.
So despite all this chest puffing, an appeal to authority would tip the scales for you?
I mean, undo alone is a killer JJ feature. Sure, you can always somehow undo any git operation if you dig deep enough, but the ease of use on the JJ side without question.
The oplog is absolutely amazing. Having such a comprehensive safety net means you can have absolutely zero fear from doing absolutely anything to your repo, because you can always return the repo itself back to a known-good state. It's git's reflog on steroids.
I’ve started using Jujutsu recently and was surprised at how low friction it was to switch. If you’re like the author and keep hearing about it without giving it a shot, I suggest you just sit down and try it – it’s a lot less effort than you might expect.
I think this is the first blog on JJ that has made me want to use it. The flow seems like it could be quite a bit better than git
Jujutsu is so good. I'm using a megamerge workflow and absolutely loving it!
How are these patch sets reviewed? Is there some mechanism for integrating with review systems like GitHub?
From git's perspective, jj bookmarks are just regular git branches, so you can just do `jj git push` and open a PR as usual.
However, unlike git, jj bookmarks are pinned to change IDs instead of immutable commit SHA-1s. This means that stacked PRs just work: Change something in the pr-1 bookmark, and all dependent bookmarks (pr-2, pr-3, ...) are automatically updated. A `jj git push --tracked` later and everything is pushed.
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.
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.
(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!!
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.
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?
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.
I started using jujutsu after the last round of blog posts here, and have found it super super useful to my mental model of git and vcs.
Stealing Fintan's `jj tug` alias from this post is something I have already found useful. Highly recommend if anyone is on the edge of trying to just give it a shot!
Just waiting for Jujutsu to support submodules and I can replace git completely.
I really hope they don't add submodule support. There's an opportunity to do something that works properly!
I feel like submodules are one of Git's most misused features. They're intended as a method of pinning read-only upstream Git dependencies. And when used for that purpose, they're good at what they do.
I think that people mostly get a bad taste in their mouths because they try to use submodules for building multi-repo workspaces where a developer might need to commit in some/all of the repos. They're a bad fit for that problem, but it's mostly because that's not what they were designed to do.
I'd love to see the jj team tackle case #2, personally. I bet they'd do a pretty good job of it.
Do you know of something that's good for what people tend to misuse Git submodules for? A multi-repo workspace thingamajig.
I think what I'd like for that is a mono-repo with better support for subsetting instead of a multi-repo with better support for unioning.
I understand that Google (and may some of the other fangs) have tooling like that internally - but I haven't had the pleasure of using it.
I tried Jujutsu on a simple repo and it ended up a mess I couldn't fix. Never had that with git. Might be my lack of knowledge but it shouldn't allow this.
jj undo, and jj op log && jj op restore can get you out of any trouble.
Follow along with Fintan as he details how he put his Git workflow into submission with Jujutsu and Radicle
Yup. Still 0 incentive to try jj. I’m still very much convinced most of the problems solved by jj either do not exist or are already solved by recent features of git.
It’s good alternatives of popular tools exist but git would not be my first bet as a tool that needs fixing…
Why say yup to disagree with the premise of the article?
Some people just enjoy being contrarian.
I always enjoy how on jj articles, 90% of commenters tried it and switched, 10% never bothered to try it, and 0% tried it but decided not to switch.
> 0% tried it but decided not to switch.
It’s trivial to prove that’s not true. Just look at the last popular Jujutsu post on HN.
https://news.ycombinator.com/item?id=44643984
https://news.ycombinator.com/item?id=44643763
https://news.ycombinator.com/item?id=44646902
https://news.ycombinator.com/item?id=44645769
https://news.ycombinator.com/item?id=44662803
https://news.ycombinator.com/item?id=44644040
And those are just the replies to the top comment which matched “went back”.
To be fair, I more or less invited these responses by bringing it up. Organically, complaints are very rare.
Obviously not everyone who tries something is going to switch, even if you take as an axiom that the other thing is objectively better. But I still think it’s notable that—without explicitly promoting that type of response—so few people seem to have negative experiences with jj given how tribal and passionate engineers tend to be over tooling.
> Some people just enjoy being contrarian.
And some people just happen to disagree - doesn't automatically mean they just like "being contrarian". I took the "Yup..." to mean "this is what I was expecting, because it agrees with what I have seen before on this topic".
> I always enjoy how on jj articles, 90% of commenters tried it and switched, 10% never bothered to try it, and 0% tried it but decided not to switch.
And some unknown quantity of readers don't see anything compelling enough to either try it and/or comment on it after they have (or have not) tried it.
I dunno, I've tried it and I think I will stick with Git for a while longer at least. I really don't like the fact that it automatically commits changes in the working tree. Apparently you can turn it off but.. yeah I dunno.
I may change my mind. Especially if they provide a less shit alternative to submodules and LFS. (And I agree this guy is just being contrarian - jj definitely does fix some Git annoyances.)
This was the thing that stopped me from giving jj a shot for the longest time, but it turned out to be a complete non-issue. Definitely don't turn it off!
The "aha" moment you might be missing is that you should consider your latest revision to just be the staging area. `jj commit -i` (shorthand for `jj describe; jj split -i`) is effectively `git add -i; git commit`. If you're worried about accidentally pushing unfinished work, don't be! It won't let you push changes without a message by default, and you update bookmarks (e.g., branch pointers) at your discretion anyway. Both of these mean that `jj git push` isn't going to accidentally push a bunch of in-flight work.
Think of it less like jj commits everything by default, and more like your working copy gets the benefits of change tracking and being able to take part in repo operations even when you haven’t taken a moment to make a commit.
You're reading an extremely biased sample of experiences. It's probably the opposite: 90% haven't tried it, 9% tried and didn't see any reason to switch, and around 1% have switched and won't shut up about it. For an advanced git user, it doesn't offer all that much. I used it for a couple of weeks and can't say that it saved me any time or any amount of work; it was either zero, or so close to zero that I wasn't able to notice it.
When Linus and his lieutenants switch over and recommend it as loudly as some do here, then I'll take another look. Very unlikely IMHO.
> For an advanced git user, it doesn't offer all that much.
As a (former) advanced git user, nothing could be further from the truth. We are always the most passionate cohort of jj users in these threads. This is almost certainly because jj unlocks a bunch of additional abilities and workflows that we've been torturing out of git (or given up on, or didn't even conceive was possible) for years.
On the flip side if all you ever do it git pull, git commit, git push, jj is probably not going to offer you much.
> 90% haven't tried it,
This is almost certainly true.
> 9% tried and didn't see any reason to switch, and around 1% have switched and won't shut up about it
This is almost certainly not true. People are far more inclined to give negative reviews than positive reviews.
So you're saying that novice jj users don't get any more benefits than they would if they made an effort to be an advanced git user?
Wow, just wow.
>For an advanced git user, it doesn't offer all that much.
arrogant, and completely absurdly wrong. I've used Git for 20 years. `jj` the single best improvement to my development workflow in... well, since adopting Git.
> I used it for a couple of weeks and can't say that it saved me any time or any amount of work
I would bet 5 figures that's a lie.
> When Linus and his lieutenants switch over and recommend it as loudly as some do here, then I'll take another look. Very unlikely IMHO.
So despite all this chest puffing, an appeal to authority would tip the scales for you?
“You miss 100% of the shots you didn’t take” - Michael Scott.
I mean, undo alone is a killer JJ feature. Sure, you can always somehow undo any git operation if you dig deep enough, but the ease of use on the JJ side without question.
The oplog is absolutely amazing. Having such a comprehensive safety net means you can have absolutely zero fear from doing absolutely anything to your repo, because you can always return the repo itself back to a known-good state. It's git's reflog on steroids.