Been using jj at work for months now. In colocated mode, JetBrains IDEs even retain some if their VCS integration.
The ability to easily work on top of an octopus merge and then push changes "down" into the contributing branches has been a live saver when my team had to do a big refactoring in a mono repo and split the changes into small PRs for individual teams (code owners).
The auto committing behavior is a bit weird at first, but now I don't want to go back to git. It feels a bit like the step from SVN to git back in the the day. ("this feels weird" -> "how did people ever tolerate the old way?")
Full agreement on both “it feels weird” -> “how do people ever tolerate the old way” as well as the auto commit behavior being one of those things. In fact I probably over-index on that specifically when talking about jj. I thought I’d hate this because I love git’s index. Turns out that by getting rid of the index, jj has a better index than git does, but that sounds insane at first!
100% agreement on that transition. I feel like I had to unlearn a lot of git’s subtly-broken model and now things feel so much simpler and easier.
One of those for me was branch names that don’t automatically “follow” new commits. At first it felt weird but it unlocks the ability to do consecutive work as one linear set of changes, even when those changes need to be merged in discrete chunks. The git approach for this (stacking branches) is so painful, particularly when you need to edit an earlier change or add a new commit between earlier ones. This went from being so frustratingly difficult I wouldn’t even consider it to being utterly trivial.
Also rebase conflicts. Not being unceremoniously dropped into a half-broken “fix this NOW state” with no ability to inspect and poke at other commits in the chain and not being able to fix things incrementally in any order is something I couldn’t have imagined. And like you said now it’s insane to me that people continue to put up with it.
To me at least it makes so much more sense to be like:
1. I am going to work on $X
2. autocommit
3. My work on $X is done
rather than
1. I make changes
2. I am done making changes
3. Now I have to describe what I changed and how
Maybe this is just me, but with git it is at times hard at times to hit the right balance in terms of commit granularity — and for my flow planning forward ("I am gonna do $X") rather than describing what I did ("I did $X") seems more.. focused?
> I also heard friends rave about "stacked diffs" but struggled to understand what exactly was going on there. Nothing I read or conversations I had have clicked.
I wonder what it is about descriptions of stacked diffs that doesn't land - it's literally just a rebase-centric workflow instead of the merge-centric workflow popularised by GitHub et al.
Steve, I see you’re in this thread. I was using jj for a while before reading your tutorial and yet still found it quite insightful and helpful. Thanks for your contribution!
I am torn between sapling and jj. Both make good progress in git/github integration which seems to have been the major road block in adoption before. One other major roadblock seems to be the limits of review tools supporting stacks: github PRs are too limited, gerrits ux is horrible, graphite does not work and is not open enough, saplings review tool is just a very slow performing POC (though with a really good UI concept as starting point)
for me important argument in favour of JJ over Sapling was "first-class conflicts" - JJ stores conflicts in the history and allows you to resolve them later, while Sapling forces you to resolve conflicts at the point when they happen
Gerrit, as I like to say, has a user interface that only a mother could love. But ultimately it's a very productive tool, so I just got over it. I even wrote some integration between jj and gerrit, making submitting stacks very easy and smooth.
IMO, Gerrit is the best currently available option by a large margin, notwithstanding its quirks.
One of my favorite people talking about my single favorite tool of the past 3+ years. Up there with (above, really) zellij and helix for changing my daily life.
Zellij looks powerful but also a bit too complex, following the "kitchen sink" school of design :-). No biggie but its name is too close to IntelliJ imho. What kind of workflow do you use with it?
I used tmux a bit back in the day, but these days I feel like good old tabs and app windows cover my needs. When I want to multiplex processes in a single window, I reach for Overmind. [1]
nice to see zellij+helix combo users out there. Helix been my fav editor for like a year already, zellij is also a daily driver, and now i'm learning jj :P
Love it, read a couple of chapters already and planning to finish the rest. As a person completely new to jj and someone who also enjoys git CLI, this is an intuitive, very useful and enjoyable read.
I’m especially interested after learning about the git compatible backend:
> There's one other reason you should be interested in giving jj a try: it has a git compatible backend, and so you can use jj on your own, without anyone else you're working with to convert too.
This was informative, thanks Steve! The only problem I had was that the difference between changes and commits wasn't clarified enough in the beginning, and I got lost trying to distinguish between the two. I'm on chapter 4 and I'm still not sure what a change is and what a commit is.
From a tiny bit of previous jj experience, my mental model is "a commit is the snapshot, and a change is what happened between snapshots", but that might be wrong. It would be great if this could be clarified a bit more in the tutorial.
I’ve started to use jj much more often (and actually used this tutorial to get me started!). I do wish its interaction with Nix flakes is less annoying though, but that’s not the fault jj.
I get that naming is one of the hardest problems in computer science, but naming software after a martial art is just lazy and will lead to problems with things like searches
If it helps, they actually named it after their desired CLI abbreviation:
> The command-line tool is called jj for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj".
I’ll just be honest with you: Pijul never really caught my interest, but I always felt pretty neutral about it until I started noticing the project authors acting very snide and aggressive on here. That is not something I want to be around these days, and so I doubt I’ll ever try Pijul.
Steve wrote this in a very approachable style. It is the first time I really understood what 'jj' is about. I'm actually kind of excited to start using this tool with my git repos.
I’d love a Sapling vs JJ comparison post. I use Sapling at the day job and… it’s pretty dang good! Although I don’t see how I’d recommend it outside of Meta.
I swear the modern programmer doesn’t realize how extremely bad Git is. It does do a lot of things better than SVN. But it’s a long, long ways from “good” imho.
I blame GitHub. Git didn’t win because it’s good. Git won because GitHub won. If only HgHub had won instead, alas.
My dream VCS system would have a virtual file system, copy-on-write storage, and a system wide blob cache. The goal being to allow open source repos to commit *ALL* their dependencies, up to and including toolchains in many cases.
I used Sapling for many months before switching to JJ. In my mind -- and I'm insanely biased as I am a JJ developer at this point -- they are both leagues ahead of Git, but I think JJ's Git interop, conflict handling, and general UX make it much more powerful and general than Sapling. Conflict handling alone is leagues better. (Martin worked on version control for a long time, and JJ is a tool that can only be created by someone with deep expertise in the domain, which I think shows itself over and over again in its use.)
If you are already using Sapling then at least trying it should be fairly easy and familiar. You could also write a JJ backend for Mononoke and EdenFS if you wanted and then use it at work ;) You wouldn't be the first JJ user from Meta, actually...
We do have plans to explore server-side designs with virtual filesystems, chunked storage, etc. There's nothing concrete yet.
(Another benefit is that JJ is much easier to write patches and contribute to due to being a relatively new, small Rust project, whereas Sapling is much more developed but much bigger and harder to get into, I think.)
Interesting. I'm not a professional developer and also love fossil for toy/hobby projects. I find it fascinating that this well crafted, solid piece of software is so forgotten, and that git has just rolled over everything.
Yeah, I was also wondering 'Traditional JJ or BJJ?'
I've never really messed around with VCSes other than git and Subversion, there's people who really like Mercurial though, so I wonder how jj compares to that.
Same. I miss the old times when people tried naming their projects sensibly. I mean, we're constantly telling ourselves how variable and function names should speak for themselves, but then we name our projects using random, completely non-descript names. It's a annoying.
[+] [-] videlov|1 year ago|reply
[+] [-] klauserc|1 year ago|reply
The ability to easily work on top of an octopus merge and then push changes "down" into the contributing branches has been a live saver when my team had to do a big refactoring in a mono repo and split the changes into small PRs for individual teams (code owners).
The auto committing behavior is a bit weird at first, but now I don't want to go back to git. It feels a bit like the step from SVN to git back in the the day. ("this feels weird" -> "how did people ever tolerate the old way?")
[+] [-] steveklabnik|1 year ago|reply
[+] [-] stouset|1 year ago|reply
One of those for me was branch names that don’t automatically “follow” new commits. At first it felt weird but it unlocks the ability to do consecutive work as one linear set of changes, even when those changes need to be merged in discrete chunks. The git approach for this (stacking branches) is so painful, particularly when you need to edit an earlier change or add a new commit between earlier ones. This went from being so frustratingly difficult I wouldn’t even consider it to being utterly trivial.
Also rebase conflicts. Not being unceremoniously dropped into a half-broken “fix this NOW state” with no ability to inspect and poke at other commits in the chain and not being able to fix things incrementally in any order is something I couldn’t have imagined. And like you said now it’s insane to me that people continue to put up with it.
[+] [-] atoav|1 year ago|reply
1. I am going to work on $X
2. autocommit
3. My work on $X is done
rather than
1. I make changes
2. I am done making changes
3. Now I have to describe what I changed and how
Maybe this is just me, but with git it is at times hard at times to hit the right balance in terms of commit granularity — and for my flow planning forward ("I am gonna do $X") rather than describing what I did ("I did $X") seems more.. focused?
[+] [-] conaclos|1 year ago|reply
I am a bit skeptical about this, because this requires a jj daemon?
[+] [-] swiftcoder|1 year ago|reply
I wonder what it is about descriptions of stacked diffs that doesn't land - it's literally just a rebase-centric workflow instead of the merge-centric workflow popularised by GitHub et al.
[+] [-] phildenhoff|1 year ago|reply
[+] [-] jFriedensreich|1 year ago|reply
[+] [-] sheremetyev|1 year ago|reply
https://martinvonz.github.io/jj/latest/sapling-comparison/
[+] [-] aseipp|1 year ago|reply
IMO, Gerrit is the best currently available option by a large margin, notwithstanding its quirks.
[+] [-] forks|1 year ago|reply
[+] [-] steveklabnik|1 year ago|reply
And yeah, the lack of good review tooling is certainly a big issue.
[+] [-] nixosbestos|1 year ago|reply
[+] [-] emmanueloga_|1 year ago|reply
Zellij looks powerful but also a bit too complex, following the "kitchen sink" school of design :-). No biggie but its name is too close to IntelliJ imho. What kind of workflow do you use with it?
I used tmux a bit back in the day, but these days I feel like good old tabs and app windows cover my needs. When I want to multiplex processes in a single window, I reach for Overmind. [1]
--
1: https://github.com/DarthSim/overmind
[+] [-] rw_panic0_0|1 year ago|reply
[+] [-] thih9|1 year ago|reply
I’m especially interested after learning about the git compatible backend:
> There's one other reason you should be interested in giving jj a try: it has a git compatible backend, and so you can use jj on your own, without anyone else you're working with to convert too.
[+] [-] steveklabnik|1 year ago|reply
[+] [-] lawn|1 year ago|reply
I even started writing one but that was a pretty big project and I lost the motivation for it.
[+] [-] stavros|1 year ago|reply
From a tiny bit of previous jj experience, my mental model is "a commit is the snapshot, and a change is what happened between snapshots", but that might be wrong. It would be great if this could be clarified a bit more in the tutorial.
[+] [-] aos|1 year ago|reply
[+] [-] spott|1 year ago|reply
[+] [-] chaostheory|1 year ago|reply
[+] [-] red_admiral|1 year ago|reply
[+] [-] riwsky|1 year ago|reply
> The command-line tool is called jj for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj".
[+] [-] stavros|1 year ago|reply
[+] [-] ZoomZoomZoom|1 year ago|reply
[+] [-] steveklabnik|1 year ago|reply
[+] [-] cinntaile|1 year ago|reply
[+] [-] nextaccountic|1 year ago|reply
[+] [-] drudru|1 year ago|reply
[+] [-] steveklabnik|1 year ago|reply
Just want to point out that this hasn’t been updated in a minute, and in particular, you’ll get some messages about branches being bookmarks now: https://github.com/steveklabnik/jujutsu-tutorial/pull/34
I have started on a second iteration of the tutorial in private, and am gonna see if I can get it in shape this weekend.
Happy to answer questions about jj!
[+] [-] miguelxpn|1 year ago|reply
[+] [-] forrestthewoods|1 year ago|reply
I swear the modern programmer doesn’t realize how extremely bad Git is. It does do a lot of things better than SVN. But it’s a long, long ways from “good” imho.
I blame GitHub. Git didn’t win because it’s good. Git won because GitHub won. If only HgHub had won instead, alas.
My dream VCS system would have a virtual file system, copy-on-write storage, and a system wide blob cache. The goal being to allow open source repos to commit *ALL* their dependencies, up to and including toolchains in many cases.
[+] [-] aseipp|1 year ago|reply
If you are already using Sapling then at least trying it should be fairly easy and familiar. You could also write a JJ backend for Mononoke and EdenFS if you wanted and then use it at work ;) You wouldn't be the first JJ user from Meta, actually...
We do have plans to explore server-side designs with virtual filesystems, chunked storage, etc. There's nothing concrete yet.
(Another benefit is that JJ is much easier to write patches and contribute to due to being a relatively new, small Rust project, whereas Sapling is much more developed but much bigger and harder to get into, I think.)
[+] [-] leighleighleigh|1 year ago|reply
[+] [-] cyanf|1 year ago|reply
[+] [-] steveklabnik|1 year ago|reply
[+] [-] itohihiyt|1 year ago|reply
I don't particularly like git and for personal projects use fossil instead.
Without going through the whole tutorial, and doing a lot more reading, why should I consider using this over fossil?
[+] [-] abc123abc123|1 year ago|reply
[+] [-] tmtvl|1 year ago|reply
I've never really messed around with VCSes other than git and Subversion, there's people who really like Mercurial though, so I wonder how jj compares to that.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] kettleballroll|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] red_admiral|1 year ago|reply
I recommend looking up Bartitsu (that Conan Doyle spelled Baritsu), a short-lived but very interesting martial art.