4 ms·
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
by KingMob 1y ago
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.
- 1718627440 1y agoAh, 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.
- KingMob 1y agoYeah, 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.
- steveklabnik 1y agoYeah 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.
- 1718627440 1y agoYou can have merge conflicts, when you combine two commits (--amend in git terminology, not sure how it's called in jj)?
- steveklabnik 1y agoOh, 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.
- 1718627440 1y agoSo the history of the second commit gets discarded?
- steveklabnik 1y agoAh, I see what you're saying. I think so, the evolog ends up showing that stuff was squashed elsewhere, I believe.