Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?


Until 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.


The same way Git ensures that no two repos generate the same commit ID: by using a cryptographic hash function.


What does JJ hash here, when I can modify the whole commit, but the change id stays constant?


The 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: