About
jj is a Git-compatible version control system that is both simple and powerful. See
the installation instructions to get started.
Release highlights
Support for uploading changes to Gerrit ...
jj is built on top of Git. If you use “colocated” repositories (which is now the default), your Git workflows will still work. In fact, all my Nvim setup with Git plugins didn’t need any change. When your run jj commands, they will operate on the Git repo, and if you run Git commands, they will be imported by jj as needed. I’ve been using almost exclusively jj at work and in open-source contributions, and so far no one has noticed (why should they).
As to why you should use it, let’s say that it encourages you to have a better development workflow, a cleaner Git history, and an easier time working on top of code that is being reviewed, by lowering the barrier. Rebase is easier to use, absorb and squash are a godsend for keeping a clean history, and a lot of design decisions that, when you think about it, just makes sense from a usability perspective.
I encourage you trying it out, I certainly don’t regret it, it does feel a lot easier to use than bare Git.
nice. this is a detail that i needed to know that would otherwise be a dealbreaker.
i am intrigued by the promises of better histories, since i’ve been reviewing and contributing to a bunch of repos at work.
a lot easier to use
see this is the issue. i don’t find git hard to use. and i’m not going to be one of those assholes that’s like “i never thought it was hard”; i’ve just genuinely been at this for over a decade now. and i run nushell so i’m not opposed to new niche things as long as it improves my workflow.
jjis built on top of Git. If you use “colocated” repositories (which is now the default), your Git workflows will still work. In fact, all my Nvim setup with Git plugins didn’t need any change. When your runjjcommands, they will operate on the Git repo, and if you run Git commands, they will be imported byjjas needed. I’ve been using almost exclusivelyjjat work and in open-source contributions, and so far no one has noticed (why should they).As to why you should use it, let’s say that it encourages you to have a better development workflow, a cleaner Git history, and an easier time working on top of code that is being reviewed, by lowering the barrier. Rebase is easier to use, absorb and squash are a godsend for keeping a clean history, and a lot of design decisions that, when you think about it, just makes sense from a usability perspective.
I encourage you trying it out, I certainly don’t regret it, it does feel a lot easier to use than bare Git.
nice. this is a detail that i needed to know that would otherwise be a dealbreaker.
i am intrigued by the promises of better histories, since i’ve been reviewing and contributing to a bunch of repos at work.
see this is the issue. i don’t find git hard to use. and i’m not going to be one of those assholes that’s like “i never thought it was hard”; i’ve just genuinely been at this for over a decade now. and i run
nushellso i’m not opposed to new niche things as long as it improves my workflow.i’ll have to check it out again.