3 ms·

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

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?

pokstad 5mo ago
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.
ulrikrasmussen 5mo ago
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/`.
- fwip 5mo ago
  "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.
  - ulrikrasmussen 5mo ago
    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
  - mystifyingpoi 5mo ago
    "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.
    - fwip 5mo ago
      /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.
- weaksauce 5mo ago
  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
  - ulrikrasmussen 5mo ago
    True, but TFA did not actually present any use cases.
adregan 5mo ago
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).
deleted 5mo ago
[deleted]
deleted 5mo ago
[deleted]
dist-epoch 5mo ago
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.
retired_account 5mo ago
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.
- bregma 5mo ago
  > 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.
m463 5mo ago
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.
- adastra22 5mo ago
  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.
  - leephillips 5mo ago
    Yeah, I don’t get it either. The command is `git init` and you’re done.
  - mystifyingpoi 5mo ago
    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.
    - adastra22 5mo ago
      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.
  - m463 5mo ago
    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?
XorNot 5mo ago
Within certain bounds git behaves quite nicely with a directory of bare git repos and Syncthing.
- deleted 5mo ago
  [deleted]
ok123456 5mo ago
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.
- gcarvalho 5mo ago
  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.
  - ok123456 5mo ago
    If it fails, you fix the clone and push it back.
- mook 5mo ago
  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).
newsoftheday 5mo ago
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).
pglevy 5mo ago
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.
tracker1 5mo ago
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.
- mystifyingpoi 5mo ago
  But "shared SSH server" isn't local.
  - tracker1 5mo ago
    Define local... Is the same room you are in local?
    - moebrowne 5mo ago
      The "local" were talking about is a path on the same machine. The article uses the remote `/home/user/bares/cani.git`
      - justsomehnguy 5mo ago
        NFS mount would be local too.
      - tracker1 5mo ago
        And local could be a separate drive, which would survive the main drive failing.
chrstphmr 5mo ago
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?

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?

pokstad 5mo ago

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.

ulrikrasmussen 5mo ago

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

fwip 5mo ago
"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.
- ulrikrasmussen 5mo ago
  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
- mystifyingpoi 5mo ago
  "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.
  - fwip 5mo ago
    /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.
weaksauce 5mo ago
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
- ulrikrasmussen 5mo ago
  True, but TFA did not actually present any use cases.

adregan 5mo ago

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

deleted 5mo ago

[deleted]

deleted 5mo ago

[deleted]

dist-epoch 5mo ago

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.

retired_account 5mo ago

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.

bregma 5mo ago
> 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.

m463 5mo ago

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.

adastra22 5mo ago
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.
- leephillips 5mo ago
  Yeah, I don’t get it either. The command is `git init` and you’re done.
- mystifyingpoi 5mo ago
  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.
  - adastra22 5mo ago
    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.
- m463 5mo ago
  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?

XorNot 5mo ago

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

deleted 5mo ago
[deleted]

ok123456 5mo ago

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.

gcarvalho 5mo ago
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.
- ok123456 5mo ago
  If it fails, you fix the clone and push it back.
mook 5mo ago
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).

newsoftheday 5mo ago

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

pglevy 5mo ago

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.

tracker1 5mo ago

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.

mystifyingpoi 5mo ago
But "shared SSH server" isn't local.
- tracker1 5mo ago
  Define local... Is the same room you are in local?
  - moebrowne 5mo ago
    The "local" were talking about is a path on the same machine. The article uses the remote `/home/user/bares/cani.git`
    - justsomehnguy 5mo ago
      NFS mount would be local too.
    - tracker1 5mo ago
      And local could be a separate drive, which would survive the main drive failing.

chrstphmr 5mo ago

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?