Network timeout error during Git push in GitKraken – retry behavior undecided

Recommended Retry Behavior for Git Push

GitKraken should not enable fully automatic, silent retries by default for all network timeouts, but it should implement a verified retry mechanism. Because Git pushes are idempotent regarding object storage—meaning the server ignores objects it already possesses—the primary risk is not data duplication, but rather an inconsistent remote reference (ref) state.

Proposed Safety Logic

To balance convenience with safety, an automatic retry should only trigger after the following verification sequence:

1. Remote Ref Check: Before resending the push, the client must query the remote ref SHA-1.
2. Comparison: If the remote ref already matches the local target commit SHA-1, the push was actually successful despite the timeout; the operation should be marked as complete.
3. Conditional Retry: If the remote ref has not changed, the push is safe to retry.

Integration with User Preferences

The existing retry count in Preferences → Git → General should act as the hard ceiling for this automation:

• Count > 0: GitKraken performs the ref check and retries automatically up to the specified limit.
• Count = 0: Automatic retries are disabled; the user is prompted immediately upon the first timeout.
• Unlimited/High Values: A system-level cap (e.g., 3–5 attempts) should be enforced to prevent infinite loops in the event of a permanent network outage or firewall block.

Technical Assumptions and Risks

This approach assumes the use of standard Git wire protocols where the server handles object deduplication. However, two risks remain:

• Bandwidth Consumption: Retrying large pushes may consume significant data if the timeout occurs during the final ref update phase.
• Rate Limiting: Aggressive retries may trigger security blocks on certain enterprise proxies or hosting providers.

Missing Diagnostic: Does the current timeout occur during the sending object phase or the updating ref phase? If timeouts occur exclusively during ref updates, the ref check becomes the mandatory first step before any retry attempt.