That's still true in jj, too.

But instead of commits, most of the time you're working with (the not greatly-named) "changes", which are a conceptual history of related commits. E.g., a single change ID points to the most recent commit in a list.

As long as you keep editing on a change, it keeps accumulating commits under the hood. When you move to another change (via `jj commit`, `jj new`, etc), all your new commits end up under a different change.

Ah, so when people here talk about changing commits they are actually talking about changing changes (nicely named, indeed)?

What happens when you merge or split changes with the change history? It sounds a bit like applying a VCS on top of a VCS.

Yeah, I love jj, but I'm not a fan of that naming. It threw me for a loop for the first couple months.

I'm not sure what happens, but I suspect a merge would create a single merge commit with the tips of the parents' histories, and then add new commits from there on.

A split is probably conceptually similar to making two new branches, except each of the new commits gets one of the branch tips. Really just guessing here, I have no idea if that's how it works, or if they share commits or not.

Yeah so people will be a bit loosey-goosey with the terminology. But all of these changes are immutable, that is, when you change a change, you’re generating a new commit. “A VCS on top of a VCS” isn’t a terrible way of thinking about it: imagine if every commit in your repo had its own history.

Merging is making a change that has more than one parent. You can then resolve any conflicts within that change.

Splitting a change into two will update one commit with one half and make a new change with the other half.

You can have merge conflicts, when you combine two commits (--amend in git terminology, not sure how it's called in jj)?

Oh, since you said 'merge' I thought you meant like git merge. Amending a commit works the same way as git. The difference is just that the oplog will have the full history, including before you amended, so you can roll back easily.

So the history of the second commit gets discarded?

Ah, I see what you're saying. I think so, the evolog ends up showing that stuff was squashed elsewhere, I believe.