[HN Gopher] The bare minimum for syncing Git repos
       ___________________________________________________________________
        
       The bare minimum for syncing Git repos
        
       Author : speckx
       Score  : 56 points
       Date   : 2026-02-17 17:35 UTC (4 days ago)
        
 (HTM) web link (alexwlchan.net)
 (TXT) w3m dump (alexwlchan.net)
        
       | donatj wrote:
       | It's interesting to me every time one of these "I just figured
       | out I can use git without GitHub" posts comes up.
       | 
       | The entire design of git was intended to be decentralized. You
       | really don't even need the centralized bare repo! You can just
       | point your machines at each other. With Tailscale these days
       | that's especially easy.
       | 
       | Admittedly, I'm getting old, but for the first couple years I
       | used git professionally ~2008-2011 we just pulled from each
       | other's machines. Directly over SSH. We worked in an office, all
       | had each other's machines as remotes. "Hey, is that feature done?
       | Cool, I'll pull it". It worked really well.
       | 
       | Eventually we tossed a bare repo up on a server in the office and
       | switched to push instead of pull. Finish a feature? Push it up!
       | At some point our devops guy installed Gitlab around that, but we
       | never really used the web ui.
       | 
       | Winds changed, we moved to GitHub, eventually a pull request /
       | code review workflow. Here we are now.
        
         | 1718627440 wrote:
         | Yeah, you can even just push to an USB stick, if you don't have
         | an Ethernet cable available.
        
           | aquariusDue wrote:
           | I sometimes clone stuff around my local filesystem and pretty
           | much yeah it's a shame GitHub has captured so much of the
           | mindshare around git.
        
         | inatreecrown2 wrote:
         | Funny you mentioned Tailscale, since the Author seems to work
         | there.
        
         | mettamage wrote:
         | > Admittedly, I'm getting old, but for the first couple years I
         | used git professionally ~2008-2011 we just pulled from each
         | other's machines. Directly over SSH. We worked in an office,
         | all had each other's machines as remotes. "Hey, is that feature
         | done? Cool, I'll pull it". It worked really well.
         | 
         | Haha I'm jealous.
         | 
         | We used Airdrop.
         | 
         | And then I was like "shouldn't we use git?"
         | 
         | "Nah, this works fine, you have the code you need now, don't
         | you?"
         | 
         | I was still in my second year of my information science
         | bachelor and he was +60 years old and had programmed for over 2
         | decades. I was not going to argue with someone that
         | experienced. In retrospect, I should have. But I'd probably
         | been shot down with being "that youngster that always wants to
         | use new technologies" (despite git not being _that_ new
         | anymore).
        
           | cratermoon wrote:
           | I recall a time when github was having an outage at the same
           | time me and a coworker were trying to fix a high priority
           | issue. I had pushed my changes before the outage but he
           | couldn't pull them. I proposed that I share my repo locally
           | so he could pull from me, but he looked confused and didn't
           | get it, so I let it drop.
        
         | pimlottc wrote:
         | GitHub did an incredibly good job of capturing mindspace around
         | git, to the extent that many users don't realize that there is
         | any distinction between the tool and the hosting platform.
        
           | varun_ch wrote:
           | I'm not sure if this is a large scale thing, but I know it's
           | definitely true for myself and some others.
           | 
           | My first exposure to Git and GitHub was through GitHub Pages.
           | I was told to use the GitHub web editor, ignore all the 'git'
           | stuff, and just write the HTML files there. Then I grew into
           | using GitHub desktop and later VSCode's git integration. At
           | no point did I have to use 'git' on the command line so I
           | didn't really understand what the tool did or why. I think
           | many people simply don't see git without GitHub. Some even
           | see GitHub without touching git eg. see the infamous 'I am
           | new to GitHub and I have lots to say' post https://www.reddit
           | .com/r/github/comments/1at9br4/i_am_new_to...
        
       | _ache_ wrote:
       | You know you can send commit by email ?
        
         | alansaber wrote:
         | Funny to imagine they may have thought this would be a key USP
         | when developing the feature.
        
           | matt_kantor wrote:
           | Git was designed for Linux kernel development, which still
           | uses email patches for contributions.
        
             | alansaber wrote:
             | I stand corrected, email appears to be a perfectly logical
             | way of sharing pull requests.
        
               | atq2119 wrote:
               | Comment threads certainly work better through email than
               | on GitHub PRs, at least when you can use a good email
               | client (i.e., running locally, and not Outlook).
               | 
               | The challenge is integration with CI and other automatic
               | work flows.
        
       | ghosty141 wrote:
       | Im quite happy with my setup.
       | 
       | I have the stock git server on a vm, gitweb to view things in the
       | browser and gitolite for basic permission management.
       | 
       | Very low tech, almost no maintenance necessary and I dont more
       | for hosting personal projects
        
       | kvikshaug wrote:
       | I had a collection of bare repos like this on a private server
       | for a while, but eventually decided to move them to a self-hosted
       | forgejo instance. It provides a nice web interface, and can be
       | configured to create a new repo simply by pushing to a new non-
       | existing repo name, super handy.
        
       | jonathanlydall wrote:
       | > You can't push changes to a non-bare repo - if you try, Git
       | will reject your push.
       | 
       | You can push to a folder with a non-bare Git repo, it's just that
       | you can't push the same branch which it has checked out.
       | 
       | Or in other words, if you get an error when trying to push to a
       | folder with a checked out repo, push to a different remote
       | branch.
       | 
       | (I do this regularly between WSL and the Windows host)
        
       | pwdisswordfishy wrote:
       | > You can't push changes to a non-bare repo - if you try, Git
       | will reject your push.
       | 
       | Sure you can. If the repo has branch foo checked out, but you're
       | changing branch bar, it will happily let you push to bar (or
       | bar->baz). And even if both are working with the same branch,
       | whether or not you get a warning or it's accepted or rejected is
       | controlled by 'receive.denyCurrentBranch'.
       | 
       | > Because nobody can "work" inside a bare repo, it's always safe
       | to receive pushes from other locations
       | 
       | Mmm... it's "safe" depending on what you're pushing and what's on
       | the other end, which is no different from trying to push to a
       | non-bare repo.
        
         | tonymet wrote:
         | This is one of gits best features . SSH deploys with offline
         | remote version tracking
        
           | fragmede wrote:
           | GitHub having a connection of ssh public keys is another
           | feature that's really neat. You can give someone access to
           | your server without having to give them a password somehow.
        
             | tonymet wrote:
             | Exactly. And it's great to move code around without having
             | to add keys to GitHub/gitlab. Wherever you have ssh access
             | you can push refs , build and deploy. Great for embedded
             | systems where you may have dozens and you don't want to add
             | keys to GitHub for each one.
        
             | embedding-shape wrote:
             | Another nice little "hidden" thing is that you can get
             | people's public keys from just a GitHub username, and be
             | kind of sure it is keys in active use, by doing
             | http://github.com/$username.keys.
             | 
             | Adding access to a new user? `curl
             | https://github.com/embedding-shapes.keys >>
             | /home/user/.ssh/authorized_keys`
        
               | tonymet wrote:
               | this is a really neat trick
        
               | fragmede wrote:
               | That is what I was saying. Thank you for giving the
               | instructions I didn't have the time to write out!
        
       | tonymet wrote:
       | Wait until you hear about subtree
        
       | tomjuggler wrote:
       | Cool! I wrote a similar blog post last year when I decided to
       | "Cut GitHub out of the loop"
       | 
       | https://www.circusscientist.com/2025/07/23/cutting-github-ou...
       | 
       | My motivation was mainly the fact that Bitbucket cut their free
       | tier, and who knows how long GitHub will be free? So I tried and
       | found out how easy git actually is to sync without third parties
        
         | MonkeyClub wrote:
         | > and who knows how long GitHub will be free?
         | 
         | Apparently for as long as it will enable Microsoft to profit by
         | training its LLMs on people's code.
         | 
         | For people uncomfortable with working on free/libre stuff with
         | git directly I always suggest Codeberg as an alternative, but
         | hands on git is also an excellent option.
        
       | blibble wrote:
       | I know you're not really supposed to do it, but I've kept my git
       | bare repos in syncthing for years
       | 
       | as long as you don't work on two machines at once and they're
       | always online it's ... fine
       | 
       | (I do have a daily backup though)
        
       | socalgal2 wrote:
       | It's common to sync via ssh                   git clone
       | ssh://mydyn.dns/path/to/repo
       | 
       | If you have unique ssh settings you can put them in .ssh/config
       | 
       | but fyi, depending on your needs, git clone/push/pull doesn't
       | sync everything. For example it doesn't sync .git/hooks
        
       | estimator7292 wrote:
       | When I quit my last job, I was the only employee left that
       | understood our tech stack. The other was a mechanical engineer
       | and industrial designer. Because I felt that CEO could barely
       | comprehend what git is or why it's important to pay AWS on time,
       | I made a full backup of everything on a USB hard drive.
       | 
       | If you ever need to do this, it can be as simple as "git mirror",
       | with extra steps for LFS and other addons.
       | 
       | That guy definitely did not deserve me to give him $100 of my own
       | personal hard drive stash but out of some sick sense of
       | professionalism I felt I had to give him a failsafe archive.
       | Because, you guessed it, not one byte of the entire company was
       | backed up anywhere.
        
       | qudat wrote:
       | I use bare git repos and then a statically generated git web
       | viewer using https://pgit.pico.sh
        
       | mnahkies wrote:
       | > I used to throw every scrap of code onto GitHub in the vague
       | hope of "sharing knowledge"
       | 
       | I looked at a random repo today, and used some of its (MIT
       | licensed) code as a starting point.
       | 
       | It was an expo plugin for managing android key stores, I didn't
       | need most of what it did, and I went a different direction in the
       | remaining bits - but it still helped me do that quickly. That
       | won't show up in any stats the author can see, but I appreciate
       | their contribution
        
       ___________________________________________________________________
       (page generated 2026-02-21 23:01 UTC)