alt.hn

5/29/2026 at 12:45:02 PM

Local Git remotes

 https://cblgh.org/posts/local-git-remotes/

by surprisetalk

5/29/2026 at 2:51:21 PM

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.

by zenoprax

5/29/2026 at 3:07:44 PM

I use Keybase's encrypted git repo the same way (to sync "private" dotfiles across laptops / remote workstations)

by kmarc

5/29/2026 at 3:11:18 PM

How is Keybase doing these days? I stopped following after the acquisition, but I like the concept.

by theptip

5/30/2026 at 1:20:08 AM

Stalled...? I even had to look up the name using "pgp social network xlm" as search terms.

App still working tho.

by kmarc

5/29/2026 at 1:51:14 PM

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

by nasretdinov

5/29/2026 at 3:16:57 PM

Oh, that's actually really useful for my... inefficient clone of nixpkgs and the linux kernel...

by packetlost

5/29/2026 at 9:25:46 PM

Interesting; how's it compare to work trees?

by yjftsjthsd-h

5/31/2026 at 2:00:53 PM

Worktrees effectively share the entire state of the repo. Only limitation is that a branch can only be checked out in one repo at a time.

Clones only share the immutable object store

For most practical uses of same repo checking out different branches locally, worktrees are better.

The nice thing about clones is that you can have a backup clone, a wip clone, a review clone where you don't clutter the amount of local branch refs

by cerved

5/31/2026 at 7:20:16 PM

ofc if you're running AI agents in YOLO mode — clones means you don't need to worry that Sonnet is going to see your .git/index.lock file and go "this is blocking me, let's rm -f this" and corrupt all your work that you never bothered pushing

by cerved

5/30/2026 at 12:40:53 PM

Worktrees are different checkouts of the same repo. Clone with --reference is a separate repo altogether, with its own .git and worktree.

by nasretdinov

5/29/2026 at 1:41:55 PM

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?

by mystifyingpoi

5/29/2026 at 1:51:46 PM

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.

by pokstad

5/29/2026 at 8:02:17 PM

To synchronize with coding agents isolated in KVM/QEMU VMs, I use local bare repos under /home/git/ on the host.

git user is restricted to git-shell and the agent has a passwordless SSH key to access git@host:/home/git/project.git. On the host, I push/pull to git@localhost:/home/git/project.git (sidestepping fiddling with git safe.directory settings for each project).

Seemed like an easy way for local sync without giving the untrusted VM access to a writable shared filesystem?

by chrstphmr

5/29/2026 at 3:24:03 PM

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.

by ok123456

5/29/2026 at 5:24:28 PM

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

by mook

5/29/2026 at 4:31:25 PM

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.

by gcarvalho

5/29/2026 at 7:32:28 PM

If it fails, you fix the clone and push it back.

by ok123456

5/29/2026 at 5:33:52 PM

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.

by tracker1

5/29/2026 at 6:53:13 PM

But "shared SSH server" isn't local.

by mystifyingpoi

5/30/2026 at 7:52:44 AM

Define local... Is the same room you are in local?

by tracker1

5/30/2026 at 8:43:30 AM

The "local" were talking about is a path on the same machine. The article uses the remote `/home/user/bares/cani.git`

by moebrowne

5/30/2026 at 11:14:39 PM

NFS mount would be local too.

by justsomehnguy

5/29/2026 at 2:25:59 PM

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.

by dist-epoch

5/29/2026 at 1:57:47 PM

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

by adregan

5/29/2026 at 1:53:37 PM

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

by ulrikrasmussen

5/29/2026 at 3:45:34 PM

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

by weaksauce

5/29/2026 at 3:52:45 PM

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

by ulrikrasmussen

5/29/2026 at 2:22:48 PM

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

by fwip

5/29/2026 at 6:58:05 PM

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

by mystifyingpoi

5/29/2026 at 9:29:19 PM

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

by fwip

5/29/2026 at 3:20:19 PM

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

by ulrikrasmussen

5/29/2026 at 3:01:15 PM

Within certain bounds git behaves quite nicely with a directory of bare git repos and Syncthing.

by XorNot

5/29/2026 at 2:54:44 PM

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.

by tonypapousek

5/29/2026 at 2:58:32 PM

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

by bregma

5/29/2026 at 2:59:56 PM

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.

by m463

5/29/2026 at 3:03:24 PM

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.

by adastra22

5/29/2026 at 8:30:58 PM

I don't know, I just have one or more clones of this "local repo" and have no trouble blowing the clones away and starting over.

backup? peace of mind?

by m463

5/29/2026 at 6:56:24 PM

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.

by mystifyingpoi

5/29/2026 at 7:20:40 PM

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.

by adastra22

5/29/2026 at 5:35:10 PM

Yeah, I don’t get it either. The command is `git init` and you’re done.

by leephillips

5/29/2026 at 4:50:08 PM

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

by newsoftheday

5/29/2026 at 4:55:28 PM

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.

by pglevy

5/30/2026 at 12:30:09 PM

In my experience, local remotes shine when you have multiple clones of the same repo on the same machine (e.g., different working trees) and you want to share objects without re-downloading or using symlinks. Also, for quick offline backups: `git push /mnt/backup/repo.git --all` is dead simple. To answer mystifyingpoi's question, one reason to push to a local remote is if you want a separate copy that isn't affected by your branch naming—or if you're using multiple clients (like a work and personal repo) that need to sync when network is available later.

by codepack

5/29/2026 at 3:14:56 PM

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

by joeyguerra

5/29/2026 at 5:10:25 PM

> btw, Git also supports the HTTP protocol ...

In fact, Git supports any protocol! If you add a git remote like

    git remote add my-remote my-super-duper-protocol::some-sort-of-address-thingy
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.

by chriswarbo

5/29/2026 at 3:31:00 PM

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.

by jjice

5/29/2026 at 1:28:14 PM

GitHub has been such a staple of the modern dev that some are now (re)discovering git is distributed.

by antiframe

5/29/2026 at 1:37:26 PM

Everything old is new again. I wouldn't be surprised if there were people that thought GitHub invented git.

by alsobrsp

5/29/2026 at 2:29:09 PM

> thought GitHub invented git

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

by elevation

5/29/2026 at 2:52:04 PM

Do you have a source for your claims about the ARDC?

by neuronexmachina

5/29/2026 at 4:28:35 PM

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.

[0]: https://seclists.org/nanog/2019/Jul/366 [1]: https://seclists.org/nanog/2019/Jul/458

by elevation

5/30/2026 at 12:10:45 AM

From your earlier comment it sounded like there was a "heist" simply based on having a similar name. Looking into it though, it seems like the ARDC non-profit did a pretty reasonable job of proving they were the same folks who'd been managing the IP block for decades. Also, has there been any sort of allegation that they've misused the funds? From what I understand they've pretty consistently used the funds to support amateur radio.

by neuronexmachina

5/29/2026 at 1:51:15 PM

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.

by orev

5/29/2026 at 1:39:29 PM

More precisely, a movement to leave GitHub mistakenly endeavors to leave git.

by enoint

5/29/2026 at 3:29:17 PM

I know so many people I went to school with and have worked with that _still_ couldn't tell you the difference between git and GitHub.

by jjice

5/29/2026 at 3:33:06 PM

I don't think I've ever met a programmer online who didn't think git and github were the same thing.

by tardedmeme

5/29/2026 at 2:48:34 PM

One of my younger colleagues indeed displayed a mistaken impression of that kind last week.

by wanzg

5/29/2026 at 10:26:25 PM

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

by dogscatstrees

5/29/2026 at 4:14:21 PM

I do this to a ~/git-sync/<project>.git directory that's synced over Syncthing for all my personal projects it's great.

by barnabee

5/29/2026 at 2:12:51 PM

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!

by ucirello

5/29/2026 at 9:13:40 PM

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.

by joseph

5/29/2026 at 1:46:12 PM

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)

by cerved

5/29/2026 at 1:48:08 PM

At that point you might as well use a worktree[1].

[1]: https://git-scm.com/docs/git-worktree

by fphilipe

5/31/2026 at 1:29:10 PM

Doesn't work. You need to mount both the worktree and the repo which defeats the point

by cerved

5/29/2026 at 8:51:36 PM

You can't use a worktree without write access to the shared object database. You can use worktrees, or you can containerize your agents, but you can't do both.

by sciolizer

5/29/2026 at 8:48:38 PM

> hardlinks the index

I think you mean hardlinks the object database? The index (staging area) changes constantly. Not much point in hardlinking it.

Hardlinking the object database is the default behavior with you clone locally on linux. It's great for one-off clones such as CI/CD pipelines and agentic containers, but the benefit in terms of disk space saved is short-lived: as repos evolve independently, they replace their packfiles with new ones, and the new ones will not be hardlinked because they don't contain the same objects.

I like to keep bare repositories in dropbox, but I use `--no-hardlinks` when cloning, because before I did that, on one occasion, dropbox corrupted the bare repo, and my working repo was corrupted as a result.

by sciolizer

5/29/2026 at 1:50:56 PM

which harness has actual containment controls and not just suggestions?

by cyanydeez

5/29/2026 at 3:16:21 PM

Interesting that the footer of the page contains the magic string Anthropic provides to trigger model refusal (styled small and clear).

by whax

5/29/2026 at 9:11:10 PM 

    git push . <branch1>:<branch2>
    git pull . <branch2>:<branch1>

by tuyiown

5/29/2026 at 8:21:51 PM

Can it work with file://?

by shmerl

5/29/2026 at 8:41:35 PM

Yes:

    $ git init foo
    Initialized empty Git repository in .../foo/.git/
    $ git clone "file://$PWD/foo" bar
    Cloning into 'bar'...
But it's redundant:

   $ git clone bar baz    
   Cloning into 'baz'...
If you example .git/config in either clone, you'll see that remote.origin.url is the absolute path of the source repo.

Note that you can share objects across clones on the same machine in various ways. See "--local", "--shared", and "--reference" in the git-clone man page. (GitHub uses this feature heavily. Or at least they did. I have no idea what their backend implementation is these days, but they must be doing some sort of copy-on-write CAS for forks.)

by js2

5/31/2026 at 3:47:56 AM

Good to know, thanks. I should try it with vim.pack for local repos.

by shmerl

5/29/2026 at 1:52:21 PM

It’s hard to sincerely bring up things like site-to-site VPN, without condescending.

by enoint

5/29/2026 at 5:34:09 PM

[dead]

by cowmix

5/29/2026 at 2:21:50 PM

[flagged]

by thehwang

5/29/2026 at 1:42:24 PM

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.

by globular-toast

5/29/2026 at 1:46:56 PM

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.

by orev

5/29/2026 at 2:30:25 PM

OK, different meanings of word "local". TFA uses "local" to mean the same machine, not the same local network.

by globular-toast

5/29/2026 at 1:46:18 PM

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.

by Zambyte

5/29/2026 at 5:47:21 PM

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.

by cowmix