When pulling, Pijul records a “pending” patch, pulls, outputs the result and unrecords the pending patch.
I’m not sure why this error happens, since nothing should be committed in the case of a crash. The second call to pull will produce a garbage pending patch, but that one will be unrecorded at the end of the pull.
I’m leaving this open, but without a way to reproduce there isn’t much we can do. If this happens to anyone again, I’d be interested in a tarball of the repository (send it by email to pe@pijul.org
), as well as their value for ulimit
on the number of open files.
I’m closing this since I can’t reproduce. I guess it hasn’t happened again since my last comment, it could be fixed. Let’s see if someone else experiences this in the future.
The issue with the ulimit open files thing was discussed briefly on zulip. Apparently this can cause consistency issues in the following manner:
There are now overlapping conflict markers/revisions, from both the failed pull and the completed pull. The consistency issue is that
pijul reset
is not able to “fix” the repo; you’re stuck with some artifacts from the first partialapply
. This seems to happen whether the changes are in the local remote cache or not, but it doesn’t happen if the changes being applied are changes that were unrecorded and are being reapplied. It might be the case thatunrecord --reset <hashes>
applied to the new patches, thenreset
would work.