Stefan Haller 7360a8459d Give the GitHub GraphQL requests a timeout ... The http.Client used for fetching pull requests had no timeout, so on a network that silently drops packets a request could stay in flight until the OS-level TCP timeouts kick in, which can take many minutes. The fetch has no visible status, so nothing tells the user it is still running; bounding it keeps the refresh's worst case short, and the next refresh simply tries again. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>		2026-07-17 13:51:38 +02:00
..
direnv	Offer direnv .envrc approval from inside lazygit	2026-06-04 09:05:01 +02:00
git_commands	Give the GitHub GraphQL requests a timeout	2026-07-17 13:51:38 +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	Wait for the streamed command's output goroutine before reading its buffers	2026-07-17 12:19:14 +02:00
patch	Guard the patch builder against concurrent access	2026-07-17 12:35:54 +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