Stefan Haller 4052057eee Back off exponentially between lock-error retries ... The retry budget was five fixed 50ms waits (250ms total). A foreground `git status` refresh can hold index.lock for longer than that on a large repo, so the retries could be exhausted before the lock clears. Wait 20ms before the first retry and double each time, giving seven attempts over a bit more than a second — enough to outlast a slow refresh while keeping the common case (a lock that clears almost immediately) fast. The initial delay is now a runner field so tests can zero it out instead of sleeping. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>		2026-07-15 10:08:44 +02:00
..
direnv	Offer direnv .envrc approval from inside lazygit	2026-06-04 09:05:01 +02:00
git_commands	Show renamed files in the custom patch builder	2026-07-04 13:05:09 +02:00
git_config	Enable errorlint linter, and fix warnings	2025-06-30 18:30:11 +02:00
hosting_service	Optimize regex compilations	2026-05-10 15:28:14 +02:00
models	Show renamed files in the custom patch builder	2026-07-04 13:05:09 +02:00
oscommands	Use ConPTY on Windows for pty-backed command execution	2026-07-03 18:47:15 +02:00
patch	Show renamed files in the custom patch builder	2026-07-04 13:05:09 +02:00
testdata	Support opening lazygit in a submodule	2019-05-12 17:59:49 +10:00
git.go	Show renamed files in the custom patch builder	2026-07-04 13:05:09 +02:00
git_cmd_obj_builder.go	Back off exponentially between lock-error retries	2026-07-15 10:08:44 +02:00
git_cmd_obj_builder_test.go	Suppress optional locks by default again, except foreground refresh	2026-07-02 16:05:08 +02:00
git_cmd_obj_runner.go	Back off exponentially between lock-error retries	2026-07-15 10:08:44 +02:00
git_cmd_obj_runner_test.go	Back off exponentially between lock-error retries	2026-07-15 10:08:44 +02:00