If you have multiple remotes, then downtime quickly becomes a non-issue. As long as at least one remote is up, you can keep pushing and fetching. I wrote about

If you have multiple remotes, then downtime quickly becomes a non-issue. As long as at least one remote is up, you can keep pushing and fetching. I wrote about mirroring in another comment [2]: > I put together a script [0] to automate the process to set the primary remote to Sourcehut (git.sr.ht) and mirror to GitLab and GitHub. And yes, that script is in a repo that's also mirrored to GitHub and GitLab (check the README). It combines well with my `git pushall` alias [1]. > [0]: https://git.sr.ht/~seirdy/dotfiles/tree/master/Executables/shell-scripts/bin/git-remote-setup https://git.sr.ht/~seirdy/dotfiles/tree/master/Executables/s... > [1]: https://git.sr.ht/~seirdy/dotfiles/tree/master/.config/git/config#L41 https://git.sr.ht/~seirdy/dotfiles/tree/master/.config/git/c... Bonus points for having one remote being a tiny self-hosted instance, like plain git+ssh. I don't think I've had any reliability issues with plain git+ssh on an rbpi. Furthermore, using mailing lists or something like git-bug instead of a vendor-locked-in issue-tracker keeps issues decentralized and eliminates downtime. [2]: https://news.ycombinator.com/item?id=22764055 https://news.ycombinator.com/item?id=22764055