For the vast majority of use cases centralization is an essential feature. You want that single source of truth, then you can have tons of branches etc. outside but without that single source everything falls apart if you are a team of more than one person.
I'd argue that even a single developer really benefit from a "centralized" repository. It helps with maintainability, backups, syncing between machines (oh, my workstation wasn't on, can't update my laptop...).
Pulling code from random developers machines might sound pretty neat in isolation but that is the exception and an edge case to something else. And that something else should most likely be a centralized repository.
When people say they love decentralized version control I often get the impression that what they really love is local commits. There is nothing that says that you can't have local commits in a centralized version control system, it is just that being decentralized is a neat solution for many problems. But that is just an implementation detail that very few could care about, had it not been hyped to death.
Now this is something entirely different than the whole developer community putting everything in one basket (github), that's the only type of centralization worth worrying about.
> Pulling code from random developers machines might sound pretty neat
Isn't that just a straw man argument?
To the extent that it applies to distributed version control, it seems like an invented problem (i.e. I don't know anyone who uses a dvcs that pulls from 'random' developers). To the extent that it is true (we are all probably guilty of using code from developers we don't know and have not properly vetted) i t seems like just as much---if not more of a problem---with github-esque projects.
> I often get the impression that what they really love is local commits
That's a really good point I have not considered before. So would you say that git's main contribution to the development community is showing the power of a VCS with local commits? And that's why github is dominating core git?
By random developer's machines they meant the actual machines. You can technically pull from another developer's (random or not, but anyone with the repo) actual laptop rather than going through an intermediary.
That was in fact one of the arguments a few true believers used in favor of DVCS when it was still a novelty.
The think I think truly gives developers comfort, in addition to all the nice features it makes simple, is LOCKSS (Lots of Copies Keeps Stuff Safe). When everyone has a full copy of the repo, even if you generally work through an intermediary, the central repo being blown away or taken control of by a bad actor doesn't mean you need to reconstruct the history of the code from whatever single snapshot checkouts individuals happen to have.
That said, I will agree that the workflows enabled, as well as the power of a common platform, are probably what really let git and github become the new default.
edit: Also I imagine being able to paw through the entire history and bisect entirely locally are vital features for a small (but essential especially of open source) minority of developers.
I interpreted “random” in the parent comment to mean “ad hoc, but planned”. Meaning, not random, untrusted or unknown engineers, but engineers from an obvious trusted group (like my team), just accessed in an ad hoc manner.
The point being that short of choosing a convention for which person’s copy (or which machine, etc) counts as the primary source of record (which would then just be poor man’s centralization with the admin costs and maintenance of any centralization tools now a burden on the team rather than a third-party product), then interacting in an ad hoc way with even just my known team’s set of distributed clones of the project turns into a bookkeeping problem nobody wants.
I can also imagine a non-centralized model can lead to many more complicated workflow failure modes. I’m just thinking about how often novices get stuck with rebasing errors or squashing commits incorrectly, and bikeshedding arguments over whether it’s ok to ever revert master or if you should intentionally keep mistakes in the history and correct with new commits. I can imagine it being even worse when there are fewer conventions, since conventions are often the only way to avoid these bikeshedding debates about preferred git hygiene methods.
Heck even torrents which are distributed needed a central server to connect through for ages. There's definitely a benefit to having a central server that aids the sea of clients / servers to communicate.
For which they need a number of central servers. These server do not do anything with the content, but they serve to announce to any new client what other clients are there, so that these new clients can start setting up their network. Once that's done, the new clients can discover the other nodes through the nodes they just connected to, and the servers have done their job.
But the servers are necessary, as far as I know, unless you want to enumerate IP addresses and scan for open ports. Which is going to be interesting with IPv6.
The bootstrap problem isn’t generally solved though - a new client needs to know a set of other clients to connect to, same with a client that’s been turned off for a while and whose cached set of other clients aren’t online. This is solved by an always-on set of clients that these clients are statically configured with.
In theory, yes, if they go down, you could configure your client to point at another well-known client, though.
I think replying to "it doesn't have a single source of truth" with "actually there are multiple single sources of truth" kind of makes the OP's case for them.
I'd argue that even a single developer really benefit from a "centralized" repository. It helps with maintainability, backups, syncing between machines (oh, my workstation wasn't on, can't update my laptop...).
Pulling code from random developers machines might sound pretty neat in isolation but that is the exception and an edge case to something else. And that something else should most likely be a centralized repository.
When people say they love decentralized version control I often get the impression that what they really love is local commits. There is nothing that says that you can't have local commits in a centralized version control system, it is just that being decentralized is a neat solution for many problems. But that is just an implementation detail that very few could care about, had it not been hyped to death.
Now this is something entirely different than the whole developer community putting everything in one basket (github), that's the only type of centralization worth worrying about.