With the git backend, jj's change id index consistency relies on locks that aren't always available
#2193
Comments
|
@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 |
4 tasks
ilyagr
added a commit
to ilyagr/jj
that referenced
this issue
Sep 5, 2023
This will be used for context in the next commit Includes a mention of jj-vcs#2193.
ilyagr
added a commit
that referenced
this issue
Sep 6, 2023
This will be used for context in the next commit Includes a mention of #2193.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The fix to #924 relies on locks. These locks would not be available if the repo was synced with
rsyncor 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 revisionidwrongly 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 revisionidwrongly reporting that no revision with such id exists.The text was updated successfully, but these errors were encountered: