I was expecting the use of non-SSH git remotes without network access. Any mounted file system can be a valid remote such as a USB drive. I use file-based remote to keep some repos encrypted on S3 using Rclone.
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.
You can also have multiple independent git repos that don't duplicate the full object store, via git clone --reference. It's less relevant in the container era, but otherwise it can save a lot of time and disk space when cloning repos repeatedly
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.
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).
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 can imagine it being useful for some obscure setup of local CI (like Jenkins) that expects a Git URL and for whatever reason cannot just copy files from one directory to another. Or maybe Argo/Flux tinkering to mimic real repo. But nothing usual should require such tricks.
There is no such thing as a git url. It is just a URI parser for the endpoint, which could be local filesystem, NFS, SSH, etc. Being able to HTTP fetch is/was an afterthought.
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
"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.
"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.
I love reading articles like this. It's kinda of a slap in the face – "hey guys, you know that thing you've been doing for decades, well for decades you've had this ability to do it with your own stuff if you just spend a few human brain tokens on it".
While yeah it's a thing that many people already are familiar with, I don't think it hurts to push out these concepts once and a while to help spread info to recalibrate those who hadn't learned these yet. I'd rather we have a bunch of articles explaining git specifics than a bunch of engineers that don't know the difference between git and GitHub.
Then pushing/pulling `my-remote` will try to invoke a command called `git-remote-my-super-duper-protocol`, with `some-sort-of-address-thingy` in its arguments. You can implement that however you like.
I use remotes like "pkipfs::y5a9inx61aski4miz4sgmg55qgbazxhfwab3i6ee1ypa6rnumi8o", which invokes a custom git-remote-pkipfs command that pushes/pulls object data to IPFS and resolves/updates refs as subdomains of a specified pkarr address.
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 who had incorporated "Amateur Radio Digital Communications" 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.
edited: Amateur Radio Digital Communications is not an LLC
This lengthy email thread[0] indicates that Jon Postel made the assignment in 1992, that the entity "Amateur Radio Digital Communications" wasn't formed until years later, meaning Jon's assignment had to have been for a purpose and not to an entity of the same name.
The head of ARIN defends[1] the transfer throughout the thread.
That assumption has come up in almost every conversation I’ve ever had with semi-technical people regarding git, so the confusion is just a fact. It happens so often, I think Linus (or whoever controlled the git trademarks at the time) should have demanded GitHub change their name when it was launched.
you can also setup a local remote which hardlinks the index so it doesn't occupy more space. Why? Idk. You don't want to share stash, rerere-cache, branches whatever.
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)
A "local remote" is a contradiction. Unless the remote is on a different disk you are just wasting space. Even then the point of remotes is for sharing, not for backup/redundancy.
The remote can be a shared directory that multiple users have access to, and the working directory is private where each user only has private read + write access.
What if you have a few local machines you’re using for development, and want to keep them in sync? This method allows that single central repo without having to bounce all the code through a cloud hosting service.
I use them ALL THE TIME. If anything, I have my 'local remote' in my Syncthing shared dir - its great for sharing code between my dev workstation(s) w/o using Github, etc.
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.
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.
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.
Aside from that unique use case, I might consider this for storing code on a network attached drive (archival).
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.
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.
And I push to GitHub/GitLab from a repo outside the sandboxes.
btw, Git also supports the HTTP protocol ...
In fact, Git supports any protocol! If you add a git remote like
Then pushing/pulling `my-remote` will try to invoke a command called `git-remote-my-super-duper-protocol`, with `some-sort-of-address-thingy` in its arguments. You can implement that however you like.I use remotes like "pkipfs::y5a9inx61aski4miz4sgmg55qgbazxhfwab3i6ee1ypa6rnumi8o", which invokes a custom git-remote-pkipfs command that pushes/pulls object data to IPFS and resolves/updates refs as subdomains of a specified pkarr address.
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 who had incorporated "Amateur Radio Digital Communications" 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.
edited: Amateur Radio Digital Communications is not an LLC
The head of ARIN defends[1] the transfer throughout the thread.
[0]: https://seclists.org/nanog/2019/Jul/366 [1]: https://seclists.org/nanog/2019/Jul/458
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)
[1]: https://git-scm.com/docs/git-worktree