jj-init Article | Author’s Fedi Announcement
Hacker News |
The author, Chris Krycho, talks about a new decentralised version control system called Jujutsu. They detail, in-depth and with a positive skew, their experience with the tool, how it compares to git as well as the possibility of it replacing git in the future.
There’s a mixture of my own words and copy-paste of the article where relevant.
Opening Text Key Takeaways:
- Jujutsu (jj) is a new version control system from a software engineer at Google, where it is on track to replace Google’s existing version control systems
- Still in development and doesn’t have it’s own backend yet
- Built using Rust
- Problems with Git:
- Only used because it’s the standard
- Terrible user experience due to terrible CLI
- Developers only learn what they need to get by and little more
- Often suggested dev learn the internals of git but this doesn’t actually help
- Internals of git have confusing semantics which extends to the interface
- Has a Git backend so it can be used with existing git repos
- This also allows devs to use Jujutsu alongside devs who use Git
- The same dev and use Jujutsu and Git/Git-aware tools interchangeably
-
Changes are distinct from revisions: an idea borrowed from Mercurial, but quite different from Git’s model.
- Conflicts are first-class items: an idea borrowed from Pijul and Darcs.
- Supposedly has a “really good” user interface
- Currently not in a state to be used without git
The above takeaways are from the opening text before the article enters the more technical and more subjective details under the “Using Jujutsu” heading.
Other Key Takeaways:
- Fairly painless to set up. A single command and editing a .gitignore file for jj specific directories
- revisions and sets of revisions (revsets) are the the fundamental elements of Jujutsu.
- Jujutsu has its own functional language. revsets are defined using this language
- Better log output due to operators acting as functions and a templating system (based on the functional language)
- Documentation is currently written for those with good knowledge of VCSs and lacks introductory material
- A change is the equivalent of a commit but due to the nature of Jujutsu works very differently
- You can modify Change messages and files. You don’t need to do an interactive rebase. You can disable this per branch by making the branch immutable.
- You can describe (like a commit message) the change you are working on and then keep working on it because the act of describing the change is distinct from the act of “committing”.
- You can easily commit a change to multiple branches at the same time.
- Changes can be made at any point in the project history. Jujutsu inserts the change into the history and handles rebasing every child for you without the need for branching.
- Easily allows you to view how a change has evolved over time with with
obslog command
- It’s hard to select specific file changes to be committed and break them off into their own commit/change.
- In case of a conflict, Jujutsu can incorporate both the merge and its resolution (whether manual or automatic) directly into commit history.
- Because Jujutsu understands the conflict markers it can actually just handle them for you often times.
- Conflicts don’t block you from committing changes
- Simplified Squash
- Branches form naturally as you make commits, you can give branches names at any point
- More coherent CLI terminology and structure
- Git integration uses libgit2
- As yet no GUIs or IDE integrations
It seems to me that a lot of these points are about manipulating repo commit histories in a simplified manner.
Another thing to notice is that jj is capable of doing things locally that you normally would do via a forge, this does increase friction though with existing git forges.
I read some of the discussion surrounding the article. This news post was mentioned as well which mentions:
- Jujutsu also requires a [[Contributor License Agreement]] for contributions.
Sparked an Idea:
So this might be a dumb question but how feasible would it be to create a kind of interoperable protocol for version control or at least distributed version control? From what I know it doesn’t really seem possible per se but who knows worth asking.
Thinking from the perspective that the next gen of version control will need to be compatible with git. I know there’s libgit2.
circlebuilder isn’t sure if it’s feasible either.
I couldn’t find anything regarding it. Maybe a recommendation for simplifying git compatibility for new version control tools.
Don’t go there”.”