Local Git Remotes(cblgh.org)
35 pointsby surprisetalk2 hours ago9 comments
  • zenoprax3 minutes ago
    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.

  • antiframean hour ago
    GitHub has been such a staple of the modern dev that some are now (re)discovering git is distributed.
    • alsobrspan hour ago
      Everything old is new again. I wouldn't be surprised if there were people that thought GitHub invented git.
      • elevation25 minutes ago
        > 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 incorporated "Amateur Radio Digital Communications LLC" and 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.

        • neuronexmachina2 minutes ago
          Do you have a source for your claims about the ARDC?
      • wanzg6 minutes ago
        One of my younger colleagues indeed displayed a mistaken impression of that kind last week.
      • orevan hour ago
        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.
      • enointan hour ago
        More precisely, a movement to leave GitHub mistakenly endeavors to leave git.
  • nasretdinovan hour ago
    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
  • mystifyingpoian hour ago
    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?
    • pokstadan hour 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.
    • adreganan hour 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).

    • ulrikrasmussenan hour 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/`.
      • fwip32 minutes 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.
    • an hour ago
      undefined
    • an hour ago
      undefined
    • dist-epoch29 minutes 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.

  • ucirello42 minutes ago
    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!
  • cervedan hour ago
    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)

  • enointan hour ago
    It’s hard to sincerely bring up things like site-to-site VPN, without condescending.
  • thehwang33 minutes ago
    [flagged]
  • globular-toastan hour ago
    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.
    • orevan hour ago
      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.
      • globular-toast24 minutes ago
        OK, different meanings of word "local". TFA uses "local" to mean the same machine, not the same local network.
    • Zambytean hour ago
      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.