I started working on IT around 2010, and basically I was born in this world with git and Github as the de facto standard to work with others and share code. It didn’t help that it was initially built by Linux Torvalds to make a me true believer on the gospel of Git. At one of my first job I also tried subversion, but it was during a very short period of time that I cannot remember having an issue or even thinking about how it was supposed to work.

It’s been almost 15 long years building CI/CD pipelines using git as the source control. 15 years reviewing pull requests, doing rebase, bisect, worktree, amend or lately playing with sparse-checkout on big monorepos. Even when I knew there were other VCS available and even big companies such as Google or Meta use their own home grown systems, I never even thought that git would be replaced at least on my personal workflows.

But here I am, on 2025 I found out about Jujutsu and I got curious mostly because it promised a better user experience, and I thought that git user experience was fine, I assumed it could be improved but never thought it was hard in any form (This is just Curse of knowledge bias I know, I just got too comfortable working with git). But that got me into researching what was the fuzz about the new kid on the block.

Well, it got me, I had to relearn some concepts but what I loved was how easy and simple were some task I was used to do on git, such as rebase or squash or just rewriting history. I started to love revset language, even working with conflicts stopped being a hard thing to do (Spoiler Alert, you can just ignore it, and keep working until you get the time to resolve it).

❗ Caution

This blog post is going to be long, and will be splited on many different post, but it won’t replace reading from official documentation; I write about my experience and what I’ve learned. Also Jujutsu is currently under heavy development so it’s possible that many things I write today may become outdated in the future (I will try to update whenever happens).

Basics

Installation

Instructions for installing for different Linux distributions and other Operating Systems are very clear on the documentation: https://jj-vcs.github.io/jj/latest/install-and-setup/. But because we are already here, if you have cargo-bininstall in your system, install it this way:

    cargo binstall --strategies crate-meta-data jj-cli

If you need or prefer something different, check the documentation.

Clone and Init

The most common work in with git is starting new projects or cloning one from a forge such as github or gitlab.

$ jj git clone https://github.com/kubernetes/kubernetes.git

jj has a compatibility mode for git named colocate. With this mode you can run both jj and git commands at the same repository. It’s really useful if you need git features that are not implemented yet or will not be implemented on jj. Also many dev tools will not work as expected if the repository you are working is not a git repository.

💡 Tip

To clone a git repository using colocate mode:

$ jj git clone https://github.com/kubernetes/kubernetes.git --colocate

If your repository is already clone on your local, you can make it work with jj running:

jj git init -- colocate

Log and working revision

jj takes ideas from different vcs, many of those ideas I didn’t even know existed. Revisions are inspired from mercurial, and I took a while on understand them but after giving it a good amount of brain power I find it a more natural way of thinking about changes.

Keeping on kubernetes repository:

$  jj log
@  qzmttztq christopher@valerio.guru 2025-09-28 17:13:16 ae8d1294
│  (empty) (no description set)
◆  wpmytzyq 20407524+k8s-ci-robot@users.noreply.github.com 2025-09-28 09:00:16 master git_head() 5161bf00
│  (empty) Merge pull request #134268 from joshjms/gce-test-fix-etcd-manifest
~

@ Is an alias of the working copy, you can see that it also has qzmttzqt string which is a change id, that is different from the git hash, which are immutable. The working copy on jujutsu is also a commit which differs from git. (It was hard to grasp at the beginning).

Running jj st which is short for jj status shows what changes has been done on the working copy:

$ jj st
The working copy has no changes.
Working copy  (@) : qzmttztq ae8d1294 (empty) (no description set)
Parent commit (@-): wpmytzyq 5161bf00 master | ()

Here again we can see @ but also @- which is an alias for parent commit, you could go further like: @-- looking for grand dad commit. But I guess is not the best idea.

Conclusion

This is just the start, I will keep posting my experience with jujutsu and how it has changed the way I work with git.