Been fiddling with Jujutsu VCS and the simple adjustment of having to describe my change/commit *before* I start changing files is profound.
CC @cafkafk
#jj is worth learning.
I spent some time learning about the Jujutsu version control tool this weekend - reading and doing tutorials. Then did some simple things in my own repos. In a weekend, I already have a better mental model of JJ's concepts than I do after working with Git daily to weekly for almost two decades. Such good design, and natively supports pushing to Git repos, so you can use it on existing projects.
If you regularly work with source control, it's worth the time to learn:
* The main repo's README (https://github.com/jj-vcs/jj) is an excellent written summary of the project. (and a great example of a software project landing page)
* https://youtu.be/LV0JzI8IcCY?si=foexHoDpYB4euEs_ - a 20 minute video introduction to Jujutsu by the creator.
* https://steveklabnik.github.io/jujutsu-tutorial/ - Steve's Jujutsu Tutorial, spend some time with this guided tour.
* Main docs: https://jj-vcs.github.io/jj/latest/
Today on #SystemCrafters Live, we'll take a look at `jj` (Jujutsu), an interesting distributed version control system that intends to be more user-friendly than Git while having even more advanced features.
Can `jj` be a good replacement for Git in the long term? Let's find out!
Join us here:
- https://youtube.com/live/zej0A21PJyc
- https://twitch.tv/SystemCrafters
- https://systemcrafters.net/live
in your time zone: https://time.is/compare/1800_in_Athens
Had a moment today while working on niri, when jj rebasing and "delayed" conflicts helped a lot.
https://www.twitch.tv/videos/2372888936?t=0h19m34s
Sorry that it's unclear what I'm doing since I'm using jj-fzf hotkeys. The gist is:
- I rebase a commit down, causing conflicts.
- I resolve the conflict, which causes further conflicts up.
- I squash and merge stuff, *including conflicts*, *before* resolving the rest.
- I resolve the rest *when I want to*, after everything else.
No "resolve now!" interruptions.
New #Blog Post about JJ-FZF!
This post goes into the details of all new features in #jj-#fzf 0.25.0, usability improvements, compatibility issues, deprecation and also breakage. Better jj-log integration, a new script for email patches, an #Emacs hook for auto-snapshots, jj-describe with content diff, the new Evolog browser, privacy markers, and more...
The full blog post:
https://testbit.eu/2025/jj-fzf-0.25.0
And happy committing!
First impressions after using #jj full time for two weeks:
1. I regret not making the switch sooner
2. I’m never going back
I’m calling it now: this is the year a bunch of you are going to switch to using #JujutsuVCS, because it’s awesome. I’m going to keep doing my best to make #jj happen—hopefully lots more posts/videos/etc.
Some of you are hacking on side projects on vacation. Try it out! https://jj-vcs.github.io/jj/latest/
It hasn't been a problem for me yet, since I usually don't keep untracked files around.
But it seems that since version 0.22, you can add
[snapshot]
auto-track = "none()"
to #jj's config file, and it won't automatically start tracking new files!
This comment summarizes it especially well: https://github.com/jj-vcs/jj/issues/323
I also wanted to get some input from y'all on a possible UI issue I encountered.
1. Install #jj https://jj-vcs.github.io/jj/latest/install-and-setup/
2. Clone an existing Git repo using a command like `jj git clone git@github.com:ethersync/ethersync`
3. Show a graph of all changes using `jj log -r ::`
Now my question is: With your terminal's color scheme, how easy is it for you to differentiate the pink from the gray letters in the change IDs at the beginning of each line?
And do you have a color vision deficiency?
By the way, #jj prevents you accidentally editing changes you've already published. Pushed changes are marked as immutable. But before you publish them, cleaning up your local changes needs less brain cycles for me compared to Git.
Oh! There's also `jj undo`, allowing you to try new things fearlessly.
Today at #38c3, I accidentally stumbled over a jujutsu table with @timj and others, which was my reminder to tell y'all about this tool! :) I think you might like it!
- There's no index anymore! Changes you make to files are recorded automatically. Instead of using `git add -p` to put partial changes in a commit, you can use `jj split`, and use a diff editor of your choice to split up edits you've done into multiple changes.
- Many commands work on the current working copy by default, but you can also directly run them on older changes! For example, You can `jj split` an older change into two!
Here's some things that feel nice about #jj:
- It doesn't force you to deal with conflicts immediately (for example, while you're rebasing a branch). Instead, you can do it later, once you're ready.
- Changes (jj's "commits") have a stable id, even if you rewrite them.
- Anonymous branches! No need to invent silly branch names when the commits already describe what the branch does.
I've been trying the jujutsu (#jj) version control system over the past few weeks, and I think I really like it! It's Git-compatible, which means that you can use it *right now* with existing project, and to collaborate with others!
Using it feels similar to when I used git-svn to collaborate with people who insisted on using SVN back in university…
Here's my current jj tree while working on a niri PR. Got the PR itself on top of main, plus a few private/scratch changes also on top of main, selectively merged together into the working directory. I write some code, split it out into a change, then rebase and squash where needed, all quick and simple and with jj undo at an arm's reach.
I also started using jj-fzf which gives me quick one-shortcut access to the common split/squash/rebase, and of course the ever important log view.
@b0rk I worked with svn, mercurial, and self-imposed bazaar. I still don't love git, but wouldn't go back to any of these. Don't think I need to explain svn, but hg's model never quite clicked for me, and bzr was too slow and confusing at times (trying to accommodate multiple workflows).
Curiously I tried #jj last week after reading about it here, and I'm liking it a lot! Even though it copies some of the hg way, I think it does it better?
#jujutsu version control system https://martinvonz.github.io/jj/v0.13.0/
Some of the concepts of #jj scratch many of my #git itches.
For example, the working copy being a (transient) commit all the time until starting a new one, thus eliminating the staging phase.
Many new questions (itches?) though, but it's still early days for Jujutsu. Very interesting.