mirror of
https://github.com/jesseduffield/lazygit.git
synced 2026-11-04 05:06:54 -06:00
Stefan HallerandClaude Opus 4.8
ccaa96b29d
Commitd94f2f05dropped the GIT_OPTIONAL_LOCKS=0 env var that we used to set on every git command, and re-added lock suppression only as a --no-optional-locks flag on the background files refresh. The intent was sound — a foreground `git status` should persist git's refreshed stat-cache — but the change was too broad: it stopped suppressing optional locks for every other command too. The one that bites is the main-view diff. When a folder containing submodules is selected, we render `git diff --submodule -- <dir>`, and `--submodule` makes git run `git status` inside each submodule to describe its "modified" state. That status now grabs the submodule's index.lock. It runs as a PTY task on its own goroutine, so it races any submodule-mutating action the user triggers — e.g. resetting a submodule runs `git -C <submodule> stash`, which then fails with "index.lock: File exists". This is what made submodule/reset_folder flaky. `git status` is in fact the only command that takes the optional lock, but the env var also covered its use inside `git diff --submodule`, inside PTY-run commands, and inside git's own submodule child processes — none of which a per-command flag reaches cleanly. Invert the polarity to match how it worked befored94f2f05: the git command builder disables optional locks on every command by default, and the single command that benefits from taking the lock — the foreground files refresh — opts back in. This restores the original contention avoidance (including against the user's terminal git) while keeping d94f2f05's stat-cache-persistence win for the foreground refresh. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>