Hacker News Reader

Comment by colejohnson66 | Hacker News Reader

I’ve heard this over and over, but I never understood it. How is Git supposed to be decentralized when you push and pull from one place? Would you just set up multiple “origins” with each one pointing to a head maintainer’s computer (and named appropriately)? Because that sounds like a massive pain compared to a centralized system like GitHub.

Of course, there is the benefit of a VCS built on the idea of decentralization: not having to be online to make commits (cough SVN cough). But, in theory, could a centralized system work in “offline mode” like Git?

View on HN

With git, "push/pull from one place" is merely a usage/behavior convention by collaborators. Nothing about git requires push or pull, and nothing about git requires that you only use a single "canonical" repository.

The key point about git is that every copy of the repository is semantically equivalent to every other copy. The one on your local machine is a fully fledged repo just like the one on your colleague's machine and just like the one on github or wherever else a "canonical repo" is hosted.

This is utterly different from older systems like svn or perforce, where the "central server" is semantically distinct from whatever you have on your machine.

At any time, you could decide that a different instance of the repo is canonical (shared push/pull), and that's what make git decentralized.

> I’ve heard this over and over, but I never understood it. How is Git supposed to be decentralized when you push and pull from one place?

Git is a _distributed_ version control system, not a decentralized version control system. This simply means that users of the repository download the entire repository onto the machine they are making changes from. Distributed version control systems have no opinions on whether the source of truth for a given repository is decentralized, distributed, or centralized.

People push and pull from one place by convention but it was designed to pull from anywhere. The problem is PRs, issues, code review etc has become centralized. As far as the code goes they just need to host all code at their own domain and use GitHub and other services as a mirror.

"Fully offline capable" would be a better term than "decentralized" when describing git.

But, one relatively decentralized workflow that git has good support for is sending patches via email (git format-patch, git am). I believe the Linux kernel still does a large amount of its collaboration that way.

As does ffmpeg. Some more recent developers seem incredulous.

https://github.com/FFmpeg/FFmpeg/pull/153#issuecomment-15416...

I once demonstrated git format-patch and git am to someone and it was a mind-blowing moment for them. At least it was a good mind-blowing moment, unlike that link above.

> Would you just set up multiple “origins” with each one pointing to a head maintainer’s computer (and named appropriately)?

That's one way of doing it. There are others as well.

https://git-scm.com/book/en/v2/Distributed-Git-Distributed-W...

You don't push in something like git, but you also don't try to do mesh. You interact with maintainers and their trees, but not necessarily always the same.

You clone a maintainers personal tree (which can be anywhere), make the change, and email them the patch with git send-email. They then apply it with git am -3. Trusted maintainers might tell another maintainer to pull their tree from wherever they put it, but they can place it wherever in the moment, including just on their own machine - it only needs to work for a single fetch as well, and could be a new location every time.

> Would you just set up multiple “origins” with each one pointing to a head maintainer’s computer (and named appropriately)?

Yes. Instead of github.com/username/project people host git repos on their own machines.

FWIW, this is often how I interact with open-source projects. Fork my own copy on Github, clone that locally, and spin up a branch for changes/PR. But then also `git remote add upstream <them>` so that I can keep my own code up to date more easily (`git merge upstream master` from master, and then trickle that into my PRs).

> Would you just set up multiple “origins” with each one pointing to a head maintainer’s computer (and named appropriately)?

That is exactly how Linus designed it to be used, and how it was used in the early days.

Reply on news.ycombinator.com