Asking users to manually update the `push` URL every time they clone a new repository is tedious. We should make it possible for people to do both `fetch` and `push` operations using the secondary by proxying the `push` operations to the primary. ### Vision Make it possible to `git fetch` and `git push` to and from a secondary geo replica, so that a secondary geo replica can be used without needing to configure two different remotes. ### Challenges It is possible that the replication delay between the primary and secondary could be sufficiently slow that relying entirely on the secondary is problematic: - **rejected push:** Assuming a replication delay of a few minutes, user A working on the primary, and user B working on the secondary. Both users have matching local state, secondary is up to date with primary. User A makes a commit and pushes. User B fetches, but changes haven't propagated, makes commit and pushes. User B's commit is rejected because their branch has diverged. User B rebases against the secondary, but changes haven't propagated. Push still fails. - **stale fetch** A build script is triggered by a web hook and pulls changes from the stale secondary. It won't be possible to checkout the requested commit from the secondary because it is not yet available ### Approach - Start with `git push` for HTTP then SSH - Provide feedback on `git fetch` if the secondary is aware that it is stale - Investigation: does proxying `git fetch` make sense?