I began using Jujutsu as my VCS about 2 months ago. Considering most of my work is on solo projects, I love the extra flexibility and speed of being able to safely fixup recent commits. I also love not having to wrangle the index, stashes, and merges.
`lazyjj` [1] makes it easier to navigate around the change log (aka commit history) with single keypresses. The only workflow it's currently missing for me is `split`.
For the times when I have had to push to a shared git repo, I used the same technique mentioned in the article to prevent making changes to other developer's commits [2].
It's been a seamless transition for me, and I intend to use Jujutsu for years.
Huh, reading the penultimate "“Units of change” and collaboration" section reinforces the feeling that Github PRs really are a poor way to do code submission/review, and have been holding back a lot of the industry from better ways of working for a long time.
dorian-graph · 10h ago
It's maddening, considering their size, and that there are proven other examples out there of versioned change sets and divorcing the commit ID from the content ID.
account-5 · 11h ago
I would really love a comparison between JJ and fossil. I use fossil for personal projects instead of git. So I'd like to know if I should consider JJ.
graemep · 10h ago
It looks like it is aimed at larger projects, whereas fossil is nice for personal projects because it was designed by and for a small team.
JJ itself uses Github, where as fossil is very easy to self-host including issue tracking, wiki etc.
renerick · 10h ago
This article covers my own experience with JJ very accurately. I'll even go as far as to say that if had to write my own article about jj, I'd use exactly the same talking points and examples. Great writeup
dorian-graph · 10h ago
Like the author, I'd appreciate a stacked PRs approach, integrated with GitHub (unfortunately). E.g. `a → b → c → d` where I have PRs open for `b`, `c` and not yet on `d`, that are "linked" to the jj changes. So 1 change per PR or it could even be multiple. I've lately become a huge fan of git-spice, that just works.
IshKebab · 10h ago
Stacked PRs is clearly a nice workflow... except that forges like Github generally have really poor support for them.
I wish Github would just allow you to say "this PR depends on this other PR", and then it wouldn't show commits from the other PR when reviewing the stacked PR.
But as far as I know you can't do that.
xrd · 10h ago
If you change the target branch it will only show commits that are against that. I wish GitHub did that automatically because it has the parent commit tree but when do you that you'll only see commits that diverge from the target branch/pr.
Is that what you want?
IshKebab · 7h ago
Not really. I've tried that with Gitlab, but it's kind of awkward. My PR isn't to merge branch B into branch A. For instance if the project owners see the PR for B and say "yeah great! I'll merge this" and press merge, it will just merge it into branch A and then close your PR!
It's a hacky workaround at best. I want proper support. I want Github to disable the merge button until the dependencies are merged. I want it to actually list the dependencies and link to them. I want the target branch to be `main`.
I think if they did those 3 things it would go 90% of the way. Too much to ask though clearly.
aaomidi · 10h ago
That works but depending on how you merge the PR, you end up needing to do a rebase on all of your future PRs.
I really wish 1PR = 1 commit with revision based diffs. Similar to gerrit.
dorian-graph · 7h ago
Another person has commented that you can do this, but it's a little known thing. git-spice automatically manages it for you too.
steveklabnik · 6h ago
It also doesn't work from forks.
dorian-graph · 1h ago
This has annoyed me a few times, just recently a week ago. Thanks GitHub.
k__ · 10h ago
I often have "no changes" in my Codespaces, because I haven't committed then yet.
Would be nice, if Codespaces keeps the JJ change stored somewhere, so it isn't tied to the lifetime of the machine.
jffhn · 10h ago
Jujutsu - I like the name.
I often see programming as going MMA with data, until you get what you want out of it.
Using brute force algorithms is going berserk, vibe coding is spamming summons in hope they get the job done, etc.
az09mugen · 10h ago
Agreed, I'd just like to complement vibe coding feels like spamming retarded Mr Meeseeks hoping they get get the job done. It's _probabilistic programming_
abcd_f · 11h ago
A thing to learn from JJ's performance is that not everyone is cut out to direct Star Wars movies.
cadamsdotcom · 9h ago
It’s clear from multiple posts over years that jj has a better UX than plain git.
Why not just merge it into git?
yowlingcat · 11h ago
Nice writeup -- had been wondering about how it compares to Git (and any killer features) from the perspective of someone who has used it for a while. Conflict markers seems like the biggest one to me -- rebase workflows between superficially divergent branches has always had sharp edges in Git. It's never impossible, but it's enough of a pain that I have wondered if there's a better way.
steveklabnik · 6h ago
For me, it's not so much that jj has any specific killer feature, it's that it has a fewer number of more orthogonal primitives. This means I can do more, with less. Simpler, but also more powerful, somehow.
In some ways, this means jj has less features than git. For example, jj doesn't have an index. But that's not because you can't do what the index does for you, the index is just a commit, like any other. This means you can bring to bear your full set of tools for working on commits to the index, rather than it being its own special feature. It also means that commands don't need certain "and do this to the index" flags, making them simpler overall, while retaining the same power.
`lazyjj` [1] makes it easier to navigate around the change log (aka commit history) with single keypresses. The only workflow it's currently missing for me is `split`.
For the times when I have had to push to a shared git repo, I used the same technique mentioned in the article to prevent making changes to other developer's commits [2].
It's been a seamless transition for me, and I intend to use Jujutsu for years.
[1] https://github.com/Cretezy/lazyjj [2] https://jj-vcs.github.io/jj/latest/config/#set-of-immutable-...
https://github.com/idursun/jjui
JJ itself uses Github, where as fossil is very easy to self-host including issue tracking, wiki etc.
I wish Github would just allow you to say "this PR depends on this other PR", and then it wouldn't show commits from the other PR when reviewing the stacked PR.
But as far as I know you can't do that.
Is that what you want?
It's a hacky workaround at best. I want proper support. I want Github to disable the merge button until the dependencies are merged. I want it to actually list the dependencies and link to them. I want the target branch to be `main`.
I think if they did those 3 things it would go 90% of the way. Too much to ask though clearly.
I really wish 1PR = 1 commit with revision based diffs. Similar to gerrit.
Would be nice, if Codespaces keeps the JJ change stored somewhere, so it isn't tied to the lifetime of the machine.
I often see programming as going MMA with data, until you get what you want out of it.
Using brute force algorithms is going berserk, vibe coding is spamming summons in hope they get the job done, etc.
Why not just merge it into git?
In some ways, this means jj has less features than git. For example, jj doesn't have an index. But that's not because you can't do what the index does for you, the index is just a commit, like any other. This means you can bring to bear your full set of tools for working on commits to the index, rather than it being its own special feature. It also means that commands don't need certain "and do this to the index" flags, making them simpler overall, while retaining the same power.