Log and Identity

Getting back to Git amend: although I believe it is a very nice abstraction, I still see a little leaky abstraction. See this:

A---B---C          <- main (HEAD)

git log --oneline
  ddb8cf5 (main) Publish shell script

echo "fix typo" >> myfile

git commit -a --amend --reuse-message=HEAD

 git log --oneline
  bea2735 (main) Publish shell script

A---B---C'          <- main (HEAD)

Within my metaphor, I modified the last commit. Yet git log insists on screaming at me:

"Hey! That's not the same commit! It's a new one! It was ddb8cf5 before, it's bea2735 now, completely different identity!"

Do I really need this constant reminder? Must Git always be so pedantic?

When I'm writing code and collaborating with colleagues, I think at a level above SHA1s. The meaning of "the last commit" is defined by how my team and I refer to it. And honestly, we always call it "the last commit", never bea2735. Can't we just happily stay in our sweet metaphor?

A good abstraction hides what you don't need to see. Git is already willing to hide the old commit. Why not hide the change of identity too?

Immutable identity

See how Jujutsu behaves:

jj log

  @  m arialdo@ik.me 2026-06-06 15:55:54 2caa192
  │  (empty) (no description set)
  ○  v arialdo@ik.me 2026-06-06 15:55:04 ddb8cf5
  │  Log and Identity
  ○  ym arialdo@ik.me 2026-06-06 15:29:39 429aa18
  │  Publish shell script
  ...

Focus on the line:

  ○  v arialdo@ik.me 2026-06-06 15:55:04 ddb8cf5

The rightmost ddb8cf5 is the Git Commit ID, a SHA1. Also notice the v on the left. This is the Change ID, an immutable reference to what you intuitively call "the last commit".

Let's Git amend, Jujutsu style:

jj edit v
echo "fix typo" >> myfile

jj log

  ○  v arialdo@ik.me 2026-06-06 15:55:04 bea2735
  │  Log and Identity
  ○  ym arialdo@ik.me 2026-06-06 15:29:39 429aa18
  │  Publish shell script
  ...

Interesting! While the Git SHA1 changed (you expected that), the Change ID did not. You can keep calling that Change v. It will always be v. Change IDs are 128-bit, random numbers, immutable and independent of the content, so they remain stable over time.

As small as this sounds, that's a huge turning point in the way you interact with your history. It's the entry point of a rabbit hole where you manipulate history in terms of what and not in terms of how. You will see tons of similar examples while using Jujutsu.

If you think about it: Git does something similar with branches. After an amend, main points to a different commit, yet everyone still calls it main. Jujutsu brings this idea to all commits.

Reverse Hex

Won't Commit IDs and Change IDs clash? Not at all. Git's Commit IDs are rendered in hexadecimal, with digits 0 to 9 and letters A to F. Change IDs such as v and ym are rendered in reverse hexadecimal, using letters from Z to K. They never overlap: a Change ID can never be confused with a Commit ID.

Smart, isn't it?

Show me less

Have you noticed that most characters of the IDs in jj log are grayed out?

output of jj log
where change ids and Change IDs have most of their last chars grayed
out

Internally, Commit IDs are SHA1s, 160-bit numbers represented with 40-char in hexadecimal. By default Git only displays 7 characters. Why exactly 7? Because it's usually enough; there is no ambiguity. In fact, often Git could use even less. But it doesn't try to optimize.

Jujutsu goes a step further. If it realizes that 2 chars are enough, it highlights 2 chars only. 1 is enough? It uses 1 only. Why display unnecessary information?

In fact, you can even hide it completely.

Take it to the limit

By default Jujutsu:

Still displays the Git Commit ID.
Highlights the strictly necessary characters, graying out the other ones.
Displays 2 lines per commit.

When something is Good™, it deserves to be taken to the next level. So:

I just hide the Git Commit ID. It's rarely used and it can be displayed on demand.
If a Change can be unambiguously identified with w, why highlight it in wnyxkzzm instead of just displaying w? If something is unnecessary, remove it.
2 lines per commit waste valuable screen space.

Instead of:

  @  xlptstlm arialdo@ik.me 2026-06-06 17:18:46 039a04d
  │  (no description set)
  ◆  poqzxkvk arialdo@ik.me 2026-06-06 16:32:39 main 9376594
  │  Review of identity
  ~  (elided revisions)
  │ ○  zzmuxzrl arialdo@ik.me 2026-06-06 16:32:45 pages 29b4782
  │ │  typo: need -> needs
  │ ○  wuwotnsy arialdo@ik.me 2026-06-06 16:23:08 e655e34
  │ │  Review of Why
  │ ○  puvzpnwv arialdo@ik.me 2026-06-06 15:19:09 eae4a1f
  │ │  PRs are welcome
  │ ○  zzsynxzk arialdo@ik.me 2026-06-06 14:26:10 3e3cf7b
  │ │  Publish script
  │ ○  yroskows arialdo@ik.me 2026-06-06 14:08:55 af28aa37
  ├─╯  init pages branch
  ◆  zzz root() 0

I prefer:

  @  x
  ◆  po   🔒  Review of identity main
  ~  (elided revisions)
  │ ○  zzm      typo: need -> needs pages
  │ ○  w        Review of Why
  │ ○  pu       PRs are welcome
  │ ○  zzs      Publish script
  │ ○  y        init pages branch
  ├─╯
  ◆  zzz  🔒  empty

I will use this template from now on. You won't regret using it too. Read in Human Friendly Log how to configure your Jujutsu.

In practice

You've learned that Jujutsu and Git happily co-exist.

Run jj git init in any Git repo you like.
Git won't even notice: Jujutsu lives in an ignored .jj directory.
You can keep working with Git as usual.
In a sense, you can consider Jujutsu a Git client on steroids.
Try using jj log. It's harmless and often a better option than git log, because it tends to show only the information you need, hiding the inessential.
You will soon learn the Revset Language, then jj log will shine and you will probably never use git log anymore.

Let's Dive Into The Rabbit Hole

You may not have noticed, but during the "Jujutsu style amend" above, we glossed over some important details. Such as: we never committed. How could that work?

Time to find out. And time to stop talking about what can be improved, and to start learning Jujutsu for real.

Keyboard shortcuts