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.
To synchronize with coding agents isolated in KVM/QEMU VMs, I use local bare repos under /home/git/ on the host.
git user is restricted to git-shell and the agent has a passwordless SSH key to access git@host:/home/git/project.git. On the host, I push/pull to git@localhost:/home/git/project.git (sidestepping fiddling with git safe.directory settings for each project).
Seemed like an easy way for local sync without giving the untrusted VM access to a writable shared filesystem?
I use local remotes all the time for testing as a form of "local CI".
Check it out from '/tmp' and make sure it still builds.
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.
Depends on if/how you're communication and/or working with others... lets say github/devops/whatever is down... but you're still wanting to get work done and collaborating with other devs.
Being able to target a shared SSH server in your control while the upstream service is down is pretty freeing... and even if you aren't releasing to production/test/etc, you can keep making shared progress.. even more important with trunk based development.
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.
Aside from that unique use case, I might consider this for storing code on a network attached drive (archival).
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.
"network fileshare" is not local. By the same logic, I can mount S3 bucket over fuse and call it "local". Sure, it will work, but in the context it is just nonsense.
/shrug It's more local than github is. Whether it's a server running in your basement, or the filesystem served by the next rack over in your on-prem datacenter, it doesn't seem unreasonable to refer to it as 'local' in certain contexts, to contrast with remotes that are further away.
I can imagine it being useful for some obscure setup of local CI (like Jenkins) that expects a Git URL and for whatever reason cannot just copy files from one directory to another. Or maybe Argo/Flux tinkering to mimic real repo. But nothing usual should require such tricks.
There is no such thing as a git url. It is just a URI parser for the endpoint, which could be local filesystem, NFS, SSH, etc. Being able to HTTP fetch is/was an afterthought.
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 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.