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

[bgw]

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)?;

[baoyachi]

@bgw Thank you for your report. I will fix it later.