what is a "version"?

[joyously]

I have two questions that sort of go together.

1. What makes a commit immutable?
2. What feature distinguishes "version control software" from "change management software"?

[Zambito1]

What makes a commit immutable?

I want to tackle this one, because after my recent experimentation with jj I've realize the git documentation itself gets this wrong, and I think some jj documentation has inherited these errors.

Firstly, it's important to note that jj introduces a concept of changes, which are an abstraction over commits. A change is associated with (ideally, unless there is an issue causing a diverging change, which I have had happen once I think) exactly one commit at a time. The history of commits that a change is associated with can be observed using the jj obslog command.

To answer your question exactly as it is written: every commit is immutable. Commits cannot be changed. You can create a new commit using an existing commit as a starting point. Rebase, edit, move/squash, and describe (probably others too, just as an example) all do this. The old commits are still there, unchanged, after these operations, as shown by the obslog.

What I believe you mean to ask instead is: what makes a change immutable? As in, what makes it so you cannot make some change point to a new commit? I don't have the exact answer for this, but I have observed it happening if I try to jj edit a tagged change. Hopefully someone who knows more can better elaborate on this.

[joyously]

Commits cannot be changed.

I was wondering about this...
Is this the source of "hidden commits"? It seems like these would pile up pretty fast.

[thoughtpolice]

Regarding immutable revisions: they are calculated by using the immutable_heads() revset, which by default is trunk() | tags() — it's called "heads" because any ancestor of an immutable commit is by definition immutable too, so you only need to list the heads you want to start at.

You can also override immutable_heads() yourself in your own configuration. The docs are here: https://github.com/martinvonz/jj/blob/main/docs/config.md#set-of-immutable-commits

[joyously]

I read that patch terminology post in early February when is was mentioned before.

I don't understand when garbage collection happens, or if things being collected are "unreachable" otherwise, it should be kept around? Does the jj storage grow faster than a git storage, by creating all these snapshots?

I can infer an unsaid quality of trunk being no direct commits, but only merges. But then, if the immutable definition is local, it doesn't matter.

Still outstanding: what is a version? How is it referenced?

[martinvonz]

Does the jj storage grow faster than a git storage, by creating all these snapshots?

Yes. I don't have any measurements for you. It depends a lot on the project and your workflow exactly how much more. On a large project, you are probably going to create fewer commits than everyone else together, even if you count your snapshots.

Still outstanding: what is a version? How is it referenced?

I think I'm missing context. Which use of "version"?

[joyously]

I think I'm missing context. Which use of "version"?

Version as in "jj is a VCS". How do you reference a "version" in jj?

[martinvonz]

Oh, I see what you mean. I'd say version there is the same thing as a revision or a commit (i.e. they're all synonyms).

[arxanas]

I can infer an unsaid quality of trunk being no direct commits, but only merges. But then, if the immutable definition is local, it doesn't matter.

I might have been imprecise when I said "merging into trunk" — I just meant "integrating into trunk", which could be done by either merge or or rebase or committing "directly". But none of those should be a problem given the definition of "immutable", since none of those integration methods rewrite commits in the immutable set. Instead, integrating into trunk will (likely) update a branch to point to the newly-integrated commit, which will update the immutable set by definition. As far as I know, jj doesn't have any method of marking branches as "immutable" (although, by default, it will prevent "sideways" moves).