What's the purpose of this? I don't get it. Why push at all to "local remote", if you can just keep your changes on a local branch, and push it whenever "remote remote" becomes available again?
I use this to push changes to a local encrypted sparse bundle image, and then I periodically rsync that image to a remote disk. Git has no built in encrypted storage, so pushing directly to a remote means you trust that remote.
I recently did a similar thing to get all my private repos off GitHub while keeping the same git workflows and accessibility for other machines on my home network. Now my Pi is the remote for those repos.
For my selfhosting, I use local remotes the same as if I were using Github or Gitlab, as part of my CI tools chain, using a git hook script to kick off the Jenkins build on the remote directory. Everything is backed up daily and monthly (separately).
I use local remotes all the time for testing as a form of "local CI".<p>Check it out from '/tmp' and make sure it still builds.<p>For a single-dev or small team, it beats having to do github runner epicycles to accomplish the same basic goal. Add in Firejail if you want environment isolation.
I reckon most folks have made a git oopsie and needed to re-clone a repo at least once in their career.<p>Having a “local remote” would be an awfully quick way to do that, especially in situations with no/low network connection or a flakey upstream server.
A decade ago I was working with an intern who wasn’t allowed access to push to any branch. As I wanted him to get experience with the development cycle, I set up a bare repo in a shared Dropbox folder and had him push code there.<p>Aside from that unique use case, I might consider this for storing code on a network attached drive (archival).
I've used it to quickly start a git project, with source control, no credentials to deal with, etc<p>eventually I can set up a proper git repo, set up credentials, etc.<p>I think it's like how some people use 127.0.0.1 for stuff, then later expand the software engineering process to do it right.
I am also seriously puzzled and don't see the point. Why push to a local remote if the real remote is not reachable? The branch is still not leaving your machine, you are just making a copy of it in another place and now have to manage `local/` refs in addition to `origin/`.
It's useful for me to have a "production" website remote that i just run on my computer for myself locally. rsync could also work but tagging with rollbacks make it easier if something goes wrong. it's not a common thing but it's nice to have that as an option. just because you can't see the utility of it doesn't make it useless
"local" can also be a network fileshare. It could also be in a directory that is treated differently than your other checkouts - whether that's something like deployment, sharing over the web, running CI, etc.
Within certain bounds git behaves quite nicely with a directory of bare git repos and Syncthing.
I use this to work with multiple agents in multiple sandboxes - they push to the local remote instead of GitHub which is now unreliable.<p>And I push to GitHub/GitLab from a repo outside the sandboxes.