fetchGit retry functionality

[VictorEngmarkHexagon]

Is your feature request related to a problem?

Networks and servers are inherently not 100% reliable. When something fails, users can lose a lot of time having to manually retry actions. Letting users configure appropriate retry behaviour for the reliability they encounter (how many times to try, how long to wait between tries, and, ideally, how to scale the wait between tries) should avoid many of these issues impacting productivity. (The assumption is that the user has no control over the reliability of the server and connections.)

Proposed solution

• A git-fetch-attempts integer setting to mirror download-attempts. Default 1 (current behaviour).
• A git-fetch-retry-wait decimal setting which specifies how long to wait between tries in seconds. Default 0?
• A git-fetch-retry-wait-scale decimal setting which specifies how much to scale git-fetch-retry-wait between retries, to deal with overloaded servers. Between the Nth and (N+1)th try there would be git-fetch-retry-wait × git-fetch-retry-wait-scale**(N-1) seconds. That is:
  • Between the first and the second try there would be git-fetch-retry-wait seconds.
  • Between the second and third try there would be git-fetch-retry-wait × git-fetch-retry-wait-scale seconds.
  • Between the third and fourth try there would be git-fetch-retry-wait × git-fetch-retry-wait-scale² seconds.
  • Etc.
    Default 1 (no scaling).

Alternative solutions

Repurposing download-attempts to also apply to fetchGit might be a quick start, but would make it harder to split the setting later.

A workaround is to manually retry the action, either manually or by writing ad-hoc retry functionality wrapping Nix commands.

Checklist

• checked latest Nix manual (source)
• checked open feature issues and pull requests for possible duplicates

---

Add 👍 to issues you find important.