One of my favorite features of jj is file watching. Once set up, jj will snapshot the repo on every filesystem event. This means on every file save, you get a git commit! It provides arbitrarily fine-grained commit history, and works across all tools (not just your IDE). I set it up in the config and it has "just worked" ever since.

The result is that `jj evolog -p` will show detailed history of your actions. But all but the most recent commit are hidden, so neatly tucked away behind the same change as usual.

Another favorite is git no longer yelling at me and having meltdowns about switching branches - "files would be overwritten, please stash". This never happens in jj, by design. It's nicer than "auto-stash" options of recent git versions.

▲

typpilol 3 days ago | parent [-]

Wouldn't you end up with like 1 million commits in a decent size projects really quickly?

▲

rkangel 3 days ago | parent | next [-]

It's not a commit per change - all changes made since the last commit are in a new commit. You then usually do one of two things:

- Decide your changes are perfect, so add a commit message to this one and then create a new one on to to carry on

- Decide you only want some of them so use `jj split -i` to select which ones you want and then it creates two commits - the stuff you want in a new named commit, and the stuff you didn't in a new working copy commit. This is the JJ workflow equivalent to `git add -p` adding to the staging area then committing

	▲	mtndew4brkfst 9 hours ago \| parent [-]
		It is, however, a commit object per change because of how jj tracks the evolution of commits. Those intermediate/ephemeral commits will not be able to be GC'd from git object storage until they are either abandoned in jj or are removed from the jj op log. The latter of which AFAIK does not happen automatically, not even on a time/age basis. I am an extremely fervent believer in jj and use it exclusively since December '24, but I think it's useful to be accurate as possible for these kinds of trade offs. I don't use watchman snapshots specifically because of this downside.

▲

steveklabnik 3 days ago | parent | prev [-]

These are entirely local, and can be GC’d.

	▲	typpilol 3 days ago \| parent [-]
		Oh I understand. I guess it works just like the local history plugin for vscode. It makes a snapshot of every file edit as well. Thanks