The author gives an excellent opening summary of the fundamental architecture of common VCSes over time, and then accurately identifies the most painful points

The author gives an excellent opening summary of the fundamental architecture of common VCSes over time, and then accurately identifies the most painful points of (eg) git, but then dramatically understates the benefits of a good DVCS. If you need binary files or otherwise very large repos, or centralized control and auditing, or non-developers to work with it, then git has major drawbacks. However there is so much code in the world—probably the majority—that works incredibly well with the full benefits of having it all in a single git repo. Having the whole history and the ability to mutilate it at will in a very fine-grained fashion is a power tool. I like it for the same reason I like vim: the learning curve is steep, but the idea is that this is a core tool I can use across programming languages for the duration of a 40, 50, 60 year career. I don't want to conflate something as horrible as svn with a theoretical good centralized VCS, but I have to say that using svn for 5 years I had much less idea how it worked then I did after 1 year of using git. Even though git was a steeper learning curve, the concepts in it are well-defined and the low-level pieces in it have a clarity of purpose which allows some implicit reasoning about the way things work without having to go in and actually read the source. This allows the fluent practitioner to devise flexible approaches to individual problems that a less modular system can not provide. I see commit messages and history as a fine craft. With git you can commit everything in small units that make sense only during construction as you are still exploring the problem space, then you can rebase it into cohesive changesets with deep documentation and a continuously unbroken build. A centralized VCS user could only achieve the same by withholding intermediate commits; that's okay, but it can become unwieldy for large changes. With git you can use initial commits like a master woodworker uses scrap wood, structuring them one way for building, and then discarding them in favor of finished pieces built to stand the test of time, providing massive forward benefit in terms of documentation/bisectability. Having worked on at least one project with a 7-year history, I can testify that investing in history curation pays huge dividends and can well make the difference between your successors thinking of you as a solid developer or a shotgun-programming hack.