If you look more closely at what they're doing, they've actually been doing distributed development for a while; they just do it without VCS support, and admit changes to the project state in a centralized fashion. Leaving aside how the published project state gets updated, they've been emailing context diffs to the mailing list and revising them. It's a small step here to use git to keep track of what you're doing with a patch set (especially with the base state published in git), and to use git to communicate changes to reviewers. And then you find that you've got your unaccepted changes in a form that your build farm is (technically) capable of testing, and maybe you could switch to regression testing commits before updating the public repository instead of after. And then maybe you start having the reviewers see what version the author has based the patch on, and think about whether any of the features accepted since matter to that, instead of thinking that either "patch" or people will find conflicts in functionality.
In any case, they're very much not coming from a centralized development background, where people don't communicate code to each other except through the central repository.