Source control is an inherently distributed system. Each developer has their own copy of the code that are distributed across many computers, and they need to communicate between each other. That's exactly what the primary function of the software is.
That's just as true with SVN, (for the local in-progress working copies) but with a single, centralized history. Which is how most devs use git anyway (essentially emulating a centralized versioning system workflow), and in this case the distributed nature of git allowing many alternative histories is unnecessary in the best case, and massively gets in the way in the worst case (because for most projects a single history is actually a feature).
(In a very real sense, the server from Subversion does the same job of the optional server from Operational Transform: it is acting as a sequencer. The next thing we could do is replace that with proof-of-work, and then we could have a fully decentralized system with the properties of Subversion ;P.)
Git is true mesh source control system. You only need one .git folder to survive and you haven't lost anything. My memory is fuzzy but with svn if you lost the central repository you were in a world of hurt.
This is what git does right. What git lacks for me is smoothness in interaction with the user. To use git well you must think like git. Which is kinda annoying when I prefer my tools to think like me.
When I moved from svn to mercurial it was absolutely painless. On my next company git was terrible experience. I am sure that git tools and flexibility are amazing for linux kernel and other projects of the scale. But probably are overkill for smaller stuff when a more friendlier user flow will be nice.
