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

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