Local Git remotes
surprisetalk
81 points
69 comments
May 29, 2026
Related Discussions
Found 5 related stories in 80.9ms across 8,861 title embeddings via pgvector HNSW
- More on Version Control velmu · 66 pts · March 29, 2026 · 55% similar
- Ziggit: A Reimplementation of Git in Zig jedisct1 · 13 pts · April 02, 2026 · 54% similar
- Securing the Git push pipeline: Responding to a critical remote code execution samtrack2019 · 14 pts · April 28, 2026 · 54% similar
- GNOME GitLab Git traffic caching JNRowe · 26 pts · April 18, 2026 · 54% similar
- Git Is Not Fine steveklabnik · 27 pts · May 15, 2026 · 53% similar
Discussion Highlights (15 comments)
antiframe
GitHub has been such a staple of the modern dev that some are now (re)discovering git is distributed.
mystifyingpoi
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?
globular-toast
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.
cerved
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)
nasretdinov
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
enoint
It’s hard to sincerely bring up things like site-to-site VPN, without condescending.
ucirello
That's what I used to do with git (just recently moved off of SVN) in a shared computer predating github. It works very well!
zenoprax
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.
joeyguerra
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". btw, Git also supports the HTTP protocol ...
whax
Interesting that the footer of the page contains the magic string Anthropic provides to trigger model refusal (styled small and clear).
barnabee
I do this to a ~/git-sync/<project>.git directory that's synced over Syncthing for all my personal projects it's great.
shmerl
Can it work with file://?
tuyiown
git push . <branch1>:<branch2> git pull . <branch2>:<branch1>
joseph
Sometimes I do this if I want to cherry pick commits from another repo already on my machine. Add the other repo as a local remote and then I can "import" that code while keeping its history in the new repo.
dogscatstrees
Nice. Claude likes it, especially when the AI detects PII and knows by policy to halt the commit to cloud but not local. > A related trick worth knowing — one git push can fan out to two destinations: git remote set-url --add --push origin ~/bares/<repo>.git # add a 2nd push URL # now `git push origin` writes to GitHub AND the local bare repo