Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Created by
brew bump
Created with
brew bump-formula-pr
.release notes
checkout respects options for
core.protectHFS
andcore.protectNTFS
.This also adds
gitoxide.core.protectWindows
as a way to enforceadditional restrictions that are usually only available on Windows.
Note that
core.protectNFS
is always enabled by default, just likeit is in Git.
Bug Fixes
more robustness in the face of a trampling-herd of threads loading a single index.
The motivating example is here: Sporadic test failure:
scan::appmaker::scan_workflow_from_git_url
praetorian-inc/noseyparker#179Previously, it was possible for a trampling herd of threads to consolidate the
disk state. Most of them would be 'needs-init' threads which could notice that
the initialization already happened, and just use that.
But a thread might be late for the party and somehow manages to not get any
newly loaded index, and thus tries to consolidate with what's on disk again.
Then it would again determine no change, and return nothing, causing the caller
to abort and not find objects it should find because it wouldn't see the index
that it should have seen.
The reason the thread got into this mess is that the 'is-load-ongoing' flagging
was racy itself, so it would not wait for ongoing loads and just conclude nothing
happened. An extra delay (by yielding) now assures it either seees the loading state
and waits for it, sees the newly loaded indices.
Note that this issue can be reproduced with:
Commit Statistics
Commit Details
view details
core.protectHFS
andcore.protectNTFS
. (886d6b5)