I feel like git has turned into the Perl of version control systems, in both the best and worst senses of the analogy. It's a system that was designed at a very

I feel like git has turned into the Perl of version control systems, in both the best and worst senses of the analogy. It's a system that was designed at a very low level but has grown organically from there, in directions dictated by how people use it (with Linus himself having an overwhelming influence here). The real-world analogy is the probably apocryphal story about how some university/corporate campus/park whatever didn't put in paths, but instead waited a year to see where people walked and put in paths there. I first heard this story on John Siracusa's old podcast, but it's apparently been around for a long time. Some googling turned this up for yet another retelling: http://opensource.com/business/10/12/discovering-desire-lines-how-break-down-barriers-and-let-paths-emerge http://opensource.com/business/10/12/discovering-desire-line.... It's great because it really is insanely featureful compared to older VCS's, and it has absolutely enabled workflows that simply were not possible 10 years ago. On the other hand, the complexity and the inconsistencies and the TIMTOWTDIness of it all means that it is one more tool that you have to dedicate yourself to knowing inside out and thinking about all the time, as opposed to a tool that's more of a fire-and-forget thing that's easy to learn, easy to use, and never screws up (and doesn't give you enough rope to hang yourself). Somewhere among git, Perl, Python, the Linux kernel, Mercurial, various Linux distros, various BSDs, and many many proprietary software projects, there is some really awesome classic book on software engineering waiting to be written, about the pros and cons of top-down vs. bottom-up design, having a BDFL vs. community-driven design and goals, user- vs. marketing- vs. developer-driven designs, etc. Cathedral and the Bazaar doesn't count, it's way to shallow and opinionated about there being a right way to do everything. There really is no one true way to choose any of these approaches, and they all have their upsides and downsides. Maybe the best we can hope for is to be aware of these things and choose the best model on a per-project basis, and be able to adapt when that project's ideal model changes.