You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Other processes might run at the same time, try to acquire the lock, and fail.
The child process can get killed for a variety of reasons, and may not be able to clean up the lock, leading to later errors about stale lockfiles.
There are two ways to mitigate this when using git status: Either set the GIT_OPTIONAL_LOCKS environment variable to 0, or run the command as git --no-optional-locks status. This can be done for all commands, not just git status, but this currently only changes functionality for the status subcommand. I'm hoping to implement this for more commands.
libgit2 does not have the same issue as GIT_STATUS_OPT_UPDATE_INDEX is not set by default. However, shadow-rs appears to run the CLI codepaths even when the git2 feature is enabled, meaning these locks will still be taken:
As I reported in this issue in vergen-gitcl,
git status
can take a lock for performance reasons: https://git-scm.com/docs/git-status#_background_refreshThis is bad in a build script because:
There are two ways to mitigate this when using
git status
: Either set theGIT_OPTIONAL_LOCKS
environment variable to0
, or run the command asgit --no-optional-locks status
. This can be done for all commands, not justgit status
, but this currently only changes functionality for thestatus
subcommand. I'm hoping to implement this for more commands.libgit2 does not have the same issue as
GIT_STATUS_OPT_UPDATE_INDEX
is not set by default. However, shadow-rs appears to run the CLI codepaths even when thegit2
feature is enabled, meaning these locks will still be taken:shadow-rs/src/git.rs
Lines 107 to 113 in 408a718
The text was updated successfully, but these errors were encountered: