With the `git` backend, `jj`'s change id index consistency relies on locks that aren't always available

[ilyagr]

The fix to https://github.com/martinvonz/jj/issues/924 relies on locks. These locks would not be available if the repo was synced with rsync or over Dropbox, as described in https://github.com/martinvonz/jj/blob/main/docs/technical/concurrency.md.

As a result, such repositories can have their change id index corrupted. This can result, for example, in jj co revisionid wrongly reporting that no revision with such id exists.

A workaround when a repo gets corrupted is to run jj debug reindex.

---

Update: Some possible symptoms (feel free to add to the list):

• jj co revisionid wrongly reporting that no revision with such id exists.
• #3861

[ilyagr]

@yuja or anyone: feel free to add details, this bug report is mostly a stub so that I can mention refer to this bug in concurrency.md.

[Mansarde]

Just a helpful FYI for newer users (like me) confused about what the co command is: Back before v0.14.0 it was an alias for checkout, which has since been replaced with new: https://github.com/jj-vcs/jj/blob/8afd0dd8ee4d6bdc59ccf2f3334e2d0642ece64a/CHANGELOG.md?plain=1#L1014 https://github.com/jj-vcs/jj/blob/8afd0dd8ee4d6bdc59ccf2f3334e2d0642ece64a/CHANGELOG.md?plain=1#L2180