Inspecting the state of a repository

So, now we've got an empty repository. Let's take a closer look at it. The command jj log shows you a visual representation of your version history. If you run it, you should see something like this:

@  mkmqlnox alice@local 2025-07-22 20:15:56 f6feaadf
│  (empty) (no description set)
◆  zzzzzzzz root() 00000000

There's a lot going on already, so let's unpack it one-by-one. In the leftmost column, there's an @, a line and a diamond. The @ sign represents the present state of the files in the repository, also known as the "working copy". The diamond indicates an earlier state and the line connecting them means one state descends from another. Older state are at the bottom and more recent ones are at the top. In this case, the diamond is the "root", an empty state from which all others descend. It always exists and cannot be modified.

Allow me to introduce a little bit of VCS-lingo. Until now, I've used the word "state" to refer to the "working copy" (@ sign) and the "root" (diamond). These states are snapshots of your repository, storing all files in the repo and their content. The technical term for these snapshots is commit. The commit is the most important data structure in the repository and I will use that term from now on.

So what's going on to the right of the first column? That's all important metadata about your commits. Let's look at the one of the working copy commit:

mkmqlnox alice@local 2025-07-22 20:15:56 f6feaadf
(empty) (no description set)

The first word is mkmqlnox, a random-looking identification number called the change ID. Next is the email address you previously configured, indicating that you are the author of this commit. After that is a timestamp, indicating when the commit was created. Last on the first line is another random looking word f6feaadf. It's also an identification number, but this one is called the commit hash or commit ID. The change ID is more important than the commit hash, which is reflected in their position in the log output: the important one comes first. We'll discuss the purpose of these IDs in more detail later.

Note that in the example output I provide in this book, the change IDs and timestamps are not always consistent. While writing the book, I go back and forth, changing stuff and recreating my example repository. This causes change IDs and timestamps to change.

On the second line, the word "(empty)" indicates that none of the files in this commit were changed compared to the previous commit. Lastly, "(no description set)" is self-explanatory and foreshadows the possibility of giving descriptions to commits.

Even though the repository is empty at this point, we already get a decent understanding of what a repository is. It consist of a set of commits which are related to each other, where one commit is said to be the parent or the child of another. These commits store snapshots of the state of your files, as well as relevant metadata like authorship, timestamp and description.

Getting help about using Jujutsu

We've now used two of Jujutsu's commands: jj git init and jj log. There are a lot of commands and flags to modify their behavior. I will introduce everything you need, but sometimes you may need to refresh your mind. It can also just be valuable to explore on your own.

You can pass the --help flag to any command to view contextual documentation. For example, jj --help will show you the full list of top-level commands that Jujutsu supports. jj log --help will show you specific information about how to use the log command, i.e. how to modify its behavior according to your needs.

These help pages will feel overwhelming at first. But something always sticks, even if you don't notice at first. If you keep coming back, you will soon become very efficient at finding relevant information this way.