Local Git Remotes(cblgh.org) |
Local Git Remotes(cblgh.org) |
For example, `git remote -v` would show: `secure-s3 /mnt/fuse/rclone/secure-s3/git/$REPO.git`
I think concurrency is a problem with file-based remotes but for one person keeping a desktop and laptop in sync it is much simpler than running a VPS.
Putting the generic term into your corporation's name can be effective means of claiming things that don't belong to you.
Jon Postel reserved 44.0.0.0/8 for a generic purpose: "amateur radio digital communications." Decades later, there was a successful heist when some enterprising individuals incorporated "Amateur Radio Digital Communications LLC" and misrepresented to ARIN that the assignment had actually been theirs. Immediately after ARIN gave them transfer rights, they pocketed 8 figures reselling the space to Amazon.
Github obviously isn't making explicit claims like this but they benefit whenever people with purchasing power implicitly understand that github is the only option.
btw, Git also supports the HTTP protocol ...
Also handy if you're running an agent in a container on the local fs. Set up a local clone, contain the agent to that repo folder and have it hack away on that. Later, you step out of the container and do the syncing. You can't use worktrees in this situations.
Bare repos are also pretty cool. You can clone the git mailing list as a bare repo and search for threads there instead of setting up an mbox (same for the kernel obviously)
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.
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 have lots of projects under for version control with no remotes.
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.
And I recon this is the default workflow for most people most of the time.
Aside from that unique use case, I might consider this for storing code on a network attached drive (archival).
And I push to GitHub/GitLab from a repo outside the sandboxes.