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?
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.
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.
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.
Would git worktrees be useful in that use case? It just adds a new checkout in a different directory without duplicating the git data (blob storage).
I do the same sometimes, but a one-off clone is not quite the same as maintaining a "local remote" and pushing refs to it.
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.
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 reckon most folks have made a git oopsie and needed to re-clone a repo at least once in their career.
And I recon this is the default workflow for most people most of the time.
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'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 don’t understand. A proper git repo is… your git repo. Git is distributed.
I have lots of projects under for version control with no remotes.
Yeah, I don’t get it either. The command is `git init` and you’re done.
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
True, but TFA did not actually present any use cases.
"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 doubt it is safe to concurrently modify a git repo over a fileshare though. I don't understand the other use cases you mention
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.
And I push to GitHub/GitLab from a repo outside the sandboxes.