As one who has set up skunkworks git boxes before, I think OP is probably referring to the fact that there is not a no-brainer out-of-the-box way for git repos on different dev machines to autodiscover each other, even on a local network.
You can have everyone manually set up a git hosting env on their dev machine, then have everyone manually add a remote for every other developer's box, but it sure isn't convenient.
And if you settle on sharing one central box as the canonical node (which IMO is the right answer), you're no longer truly using a distributed system - it's a de facto centralized system.
Exactly, syncthing has flawless p2p discovery and networking/sharing of files. Being able to put a git bare repo effectively on a syncthing share would be super convenient for small private collaboration. Tailscale might be an option to make a bunch of local git repos all start pushing/pulling, but it has some headaches too and isn't really designed for opening up small single services.
> I think OP is probably referring to the fact that there is not a no-brainer out-of-the-box way for git repos on different dev machines to autodiscover each other, even on a local network.
Ah, OK, gotcha. Thanks!
> You can have everyone manually set up a git hosting env on their dev machine, then have everyone manually add a remote for every other developer's box, but it sure isn't convenient.
Yeah. But fortunately not all that much of a hassle for a small(ish) dev team.
> And if you settle on sharing one central box as the canonical node (which IMO is the right answer),
Yeah, we called it "the Dev server". :-)
> you're no longer truly using a distributed system - it's a de facto centralized system.
But in a corporate (or even Open Source project?) environment, The Powers That Be probably want that kind of / that much centralisation anyway.
> But in a corporate (or even Open Source project?) environment, The Powers That Be probably want that kind of / that much centralisation anyway.
Agreed. I have used git in genuinely decentralized ways and have concluded that in practice centralization is the right answer for almost all projects.
Even though having the full history locally is a transformative improvement pet Subversion's model, in practice it's really helpful to know there's a canonical source of truth and to coordinate around it.
You can have everyone manually set up a git hosting env on their dev machine, then have everyone manually add a remote for every other developer's box, but it sure isn't convenient.
And if you settle on sharing one central box as the canonical node (which IMO is the right answer), you're no longer truly using a distributed system - it's a de facto centralized system.