Comment by mystifyingpoi
1 hour ago
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?
1 hour ago
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 reckon most folks have made a git oopsie and needed to re-clone a repo at least once in their career.
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.
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.
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/`.
"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.
I use this to work with multiple agents in multiple sandboxes - they push to the local remote instead of GitHub which is now unreliable.
And I push to GitHub/GitLab from a repo outside the sandboxes.