2 ms·
How does JJ ensure that there are now change ID conflicts on push, i.e. so that no two repos generate the same change-id?
by 1718627440 1y ago
How does JJ ensure that there are now change ID conflicts on push, i.e. so that no two repos generate the same change-id?
- steveklabnik 1y agoUntil recently, change ids were entirely local (in the git backend). So conflicts just can’t happen. Recently jj started including the change id in a header in the git object, so the receiving side can choose to respect/expose them as appropriate. An issue with this is that some git commands don’t guarantee the preservation of headers, so it’s possible to accidentally lose them; git rebase being a prime example.
- SAI_Peregrinus 1y agoThe same way Git ensures that no two repos generate the same commit ID: by using a cryptographic hash function.
- 1718627440 1y agoWhat does JJ hash here, when I can modify the whole commit, but the change id stays constant?
- KingMob 1y agoThe parent comment is wrong. Generally, when a new change ID is needed, jj generates a random number. The individual commits under each change still use hashed SHAs. > when I can modify the whole commit You can't actually modify any commits. A mutable change can be thought of as a subset of immutable git commits with a pointer to the most recent commit. When you alter a file and jj snapshots, it adds immutable commits to the DAG end, and updates the pointer. --- There's some exceptions, like when importing from git, it will generate new change IDs based on a transform of the git SHAs. --- Side note: as much as I like jj, I admit the change/commit terminology is confusing as hell.