Version Control (4 blogmarks)

This article explains how jj doesn't have the concept of a branch and how you instead can use bookmarks to achieve a similar effect and interop with git.

At the end of the article are several useful jj workflows. Such as "Workflow: working alone":

If you are just making changes locally and just want to push your changes to main, you must update the bookmark before pushing with a command like jj bookmark set main -r @. This is currently the clunkiest part of jj. There have been conversations in the project about how to improve it.

If you search for jj tug online you will see a common alias people set up to automate this.

This isn't the first time I've seen someone mention the jj tug alias.

An introductory tutorial to jujutsu that is built to be accessible for someone who doesn’t have experience with Git.

If you are already experienced with Git, I recommend Steve Klabnik's tutorial instead of this one.

• Official Tutorial and Bird’s Eye View
• Steve Klabnick’s Jujutsu Tutorial
• Git and Jujutsu: In Miniature
• jj tips and tricks
• Jujutsu Introduction and Patterns
• jj init
• Configuring Jujutsu
• Understanding jujutsu bookmarks

jujutsu -- a version control system

I think what’s remarkable about Jujutsu is that it makes all those slightly exotic git workflows both normal and easy.

They go on to describe all these common git mechanics that jj makes more accessible.

Jujutsu simplifies the UX around those operations significantly, and makes some changes to the git model to make them more natural. Squash has its own command, splitting a commit into two is a first-class operation, rebase only does what the name suggests it should, and you can go back to any previous commit and edit it directly without any ceremony. Jujutsu also highlights the unique prefix of commit/change IDs in its UI, which is a small UI change but it makes it much easier to directly address change IDs because you only have to type a few characters instead of copying and pasting 40 characters. If you run into a conflict during any of these operations you don’t have to fix it right away like git: they sit in the history and you can deal with them however you want.

And a comment right below this points out that because of jj's interoperability with git, you can collocate to start using jj in an existing git project right away.

My only advice to someone truly curious about jj is to drop into any code base you’re familiar with, jj git init --colocate, and work for week only using jj. It won’t be painful. You’ll occasionally be unfamiliar with how to achieve some workflow with jj, but the docs are good and you’ll figure it out.