I've used it to quickly start a git project, with source control, no credentials to deal with, etc

eventually I can set up a proper git repo, set up credentials, etc.

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 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 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.

Within certain bounds git behaves quite nicely with a directory of bare git repos and Syncthing.

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/`.

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.