HackerNews has had Jujutsu version control post every couple of months last four years (at least). Apparently it is a thing at Google.

I am not going to talk in length about what it is - there’s documentation about it, but it is basically some Mercurial/changeset driven semantics that happen within git repo (or its own backend). It has some nice features, but also three I disliked enough to skip using it, for now.

They are listed in order of increasing importance (for me).

jj log is bit weird (and I’m not huge fan)

By default, if you don’t happen to have immutable commits, it behaves similarly to git shortlog, e.g. (with bit non-default format)

@  ny me@example.com2025-12-15 08:32:39 8a
│  (no description set)
│
○  vox me@example.com2025-12-14 20:48:47 main git_head() 122a
│  Periodic update 20251214
│
○  mr me@example.com2025-07-22 18:08:09 e2
│  Random configuration updates

However, if you have immutable heads based on which you are working on, it actually shows by default only local changes, which is different. I’m not sure if it is a problem for me though, although I found it bit distracting, as my different repos behave differently. Of course, I could configure the behaviour per repo or even globally to e.g. match git for most part, but I try not to change default behaviour of tools more than I must as I sometimes need to use them somewhere without my own configuration files.

Git(hub) interaction in typical PR workflow

In jujutsu the typical workflow when using Git is (for purposes of this flow, lets pretend bookmark is a git tag, which is close enough - fixed reference to specific thing in your version control). The fixes-as-separate-commits workflow looks like this when reacting to PR comments:

jj edit mybranch
jj new
jj commit -m"Fixed x, y, z" # commit describes changes, and starts new
jj bookmark set mybranch -r @- # point to the non-empty change
jj git push

How does it look like with git?

git checkout mybranch
git add .. # unlike Jujutsu, git doesn't automatically add files you wanted
git commit -m"Fixed x, y, z"
git push

The amount of typing is more for Jujutsu, although not by much. But whole ‘let’s remember what was name of mybookmark (branch on git side) feels just ugly and somewhat unnecessary.

Same thing also applies to the squashed rebase interactive workflow. More typing, at questionable benefit (yes, I know, stacked branches and all that, but they’re minority in my work compared to short-lived simple branches off main).

Git hooks are not supported

Or more precisely, pre-commit is not supported (see issue Integrate with https://pre-commit.com/ · Issue #405 · jj-vcs/jj). I rely on pre-commit a lot in my different repos, and I don’t really want to deal with doing things by hand.

Sure, as noted in the issue thread, you can do workarounds like this (I tried this for a bit, not happy with it):

[aliases]
# Hack when waiting for https://github.com/jj-vcs/jj/issues/405
#
# pre-committed commit
pco = [
  "util", "exec", "--", "bash", "-c", """
set -euo pipefail

# List files changed in the current working commit (`@`)
changed_files=$(jj diff --name-only -r @)

# If nothing changed, just commit normally
if [ -z "$changed_files" ]; then
  exec jj commit "$@"
fi

# Run pre-commit only on the changed files
printf '%s\n' "$changed_files" | xargs pre-commit run --files

# If pre-commit succeeded, create the commit
exec jj commit "$@"
""", ""
]

and then only use jj pco instead of jj commit, but remembering to do that, and doing same for every other built-in command to manipulate the working directory first before changing the active commit feels hard, and unnecessary.

Conclusion

I think I will reconsider Jujutsu once pre-commit (or prek or whatever) can be run on commits as needed. The git forge interaction is bit awkward with bookmark set, but I presume I could write shell aliases to find parent bookmark and update it automatically, but lack of git hook support (or equivalent) is fundamental reason for me not to bother with Jujutsu, yet.