Hacker News Reader

Comment by mystifyingpoi | Hacker News Reader

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?

View on HN

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.

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?

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.

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.

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

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

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.

But "shared SSH server" isn't local.

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

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

NFS mount would be local too.

And local could be a separate drive, which would survive the main drive failing.

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

"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

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

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

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.

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

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.

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

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.

Reply on news.ycombinator.com