> git may have become successful, but that doesn't mean it's right.
If bitbucket had that business model instead of the inverse we’d all think of git as that weird bad hg that Linus forces the Linux devs to use.
Git is a classic example of other factors than the software driving use.
Seriously give it a try
Git would be dead on the water if it wasn't for being written by Linus and a requirement to interact with Linux development.
Your statement is only true to the degree that it's a tautology: Git's popularity demonstrates that it's right and the definition of "right" is "popular".
But if you want to use "right" to mean anything else, maybe to say something about it's technical merits independent of sociological factors like the network effect, first-mover advantage, high-profile early adopter, etc. then your sentence doesn't add any information.
Personally, I think Git's user experience is an unremitting shitshow, the kind of disaster that makes one reconsider Hanlon's Razor.
The technical capabilities buried under that UX are pretty nice, though you could probably discard 1/3 of them without impacting any noticeable fraction of users.
The performance is excellent and it's very easy for developers to underrate how much that effects user satisfaction.
And it had the good fortune to win on almost all of the sociological factors that largely determine product success.
If you compare git to rival tools such as Mercurial and Fossil or even Darcs, it's pretty evident that git didn't really win on technical merit, user friendliness or indeed hardly any other metric. It was fast, and it had the dubious advantage of being better than a lot of crappy alternatives at the time, and of being the product of a famous developer. But if technical merit was how we chose software, we might all be using Mercurial today. It's quite possible we'd be better off, too.
git's punting of "certain of the hard theoretical problems" lead to major shortcomings in its design. For example, git does not track branching histories. Once you merge your changes back into a branch and delete the origin branch, the path that your commits took are lost. Another example: Since git's data model works entirely on repository snapshots (there are no "patches" or logical operations, only snapshots), it doesn't know about file renames. Some commands, like log and diff, do understand how to detect renames (but not out of the box!), but it's fundamentally a fuzzy-matching operation that can only work perfectly if you separate your rename commits from modification commits, which is rarely feasible.
Don't get me wrong, git has overall been a force for good, but I think it's a pretty terrible example in this particular case. In fact, I'm not sure I can think of many cases where the "worse is better" philosophy was ultimately a good idea. In every instance that comes to mind (MySQL, MongoDB, PHP), the fast-and-loose attitude ultimately came back to hurt everyone, and years were spent paying for those mistakes, plugging one hole at a time.
The original decision by the Go team to build package management into the language ("go get") was made without really understanding the problem, and this decision has been haunting us pretty much since day one, with developers having to chase unofficial package management tools of the week in order to get their work done. I really want it to be done right, even if takes a bit longer. It's a problem worth solving well.