[ulrikrasmussen]

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

[weaksauce]

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

[ulrikrasmussen]

True, but TFA did not actually present any use cases.

[fwip]

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

[mystifyingpoi]

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

[fwip]

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

[ulrikrasmussen]

I doubt it is safe to concurrently modify a git repo over a fileshare though. I don't understand the other use cases you mention