3 ms·
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
by steveklabnik 1y ago
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.
- 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.