Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Git commands take optional locks, can lead to stale .git/index.lock issues #221

Open
bgw opened this issue Mar 6, 2025 · 0 comments
Open

Comments

@bgw
Copy link

bgw commented Mar 6, 2025

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_refresh

This is bad in a build script because:

  • 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:

shadow-rs/src/git.rs

Lines 107 to 113 in 408a718

// First, try executing using the git command.
if let Err(err) = self.init_git() {
println!("{err}");
}
// If the git2 feature is enabled, then replace the corresponding values with git2.
self.init_git2(path)?;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant