The modding here is atrocious.
The GP is right, and you are wrong.
There is only one form of decentralization involved here.
Even if git users have their own copies of a repo, it is not trivial to share changes among more than a couple of users, especially if they are on distinct networks with firewalls and other hindrances.
That is why GitHub is used.
GitHub negates the decentralization of git in order to make it practical for real world use.
But for real projects with distributed teams consisting of numerous people the decentralization of git is a big problem.
GitHub is the only practical solution to the problems of decentralization.
This can actually be mitigated by several different means:
- 1. Using multiple Git services - e.g Git Hub AND Gitorious or Public GitHub and Git Hub for Enterprises if you use private repositories
- 2. Using your own servers as well - e.g. Qt has gitorious but also their own servers
It's just a matter of deciding where the "master" copy resides and keeping them all (hopefully automatically) in sync.
Now, this can be managed with tools like Subversion too, using replication, but it's no where near as nicely done as it is in git.
However, if you don't take the time to do the replication between several services then yes, you are risking this kind of situation.
Or, you could take advantage of this kind of replication by using the DVCS nature of git to your advantage.