I want all my code to be open source, but I will use the best tool for the job and BitKeeper was the best tool and at the time the alternatives sucked so bad they were shit. When the alternatives are so bad I will take proprietary code. Proprietary was a downside, but what choice did I have? Hey, I usually do my presentation slides in PowerPoint.
In the end BitKeeper was causing too many issues so I said I'm not using a version control system until another was suitable. I have used CVS in the past and I knew enough to know that I hated it. And I won't use Subversion as it has the same fundamental problems as CVS. In the open source world there were some small projects. Mercurial came about the same time as Git. So they were parallel and there were existing ones like Bazaar. The one I liked most is a project called Monotone. I looked at it and there are things I really liked about it and many things I disliked and performance was one of them.
I took me two weeks to get to a Git that was unusable for anyone else. The user interface was something only I could love, but after two weeks it did something that CVS and Subversion didn't do and that was merge correctly with history and everything. Then I took two years after that to get it useful and have an interface that people could use.
If you have the right idea you can do that well, but it takes a long time to refine it.
It's not uncommon for a project to have an official model, like Subversion, but then people would use Git for merges and then export the end result back to the official project. Now, just in the last couple of months, projects have started switching to Git. Perl is one of the better-known ones and Git uses Perl internally so it was a positive feedback cycle.
To some degree source control management is such a core technology it's important to know how it works and if you don't know it you are spending a lot on mental effort on knowing what it's doing. Just through the kernel there were thousands of people who knew Git and then it was viral where other projects started using it.
Git has always had a "Unixy" mindset where you create commands. So we never did what other projects do where they have an API and a scripting language built into it. It's partly a design issue and for other reasons. So it can be hard to write a program that accesses Git internally as there are no libraries. It turns out the best way to interface with it is with Java.
One of the things I like about Git, and am quite proud of, is the data structures are simple and you can re-implement it if you wish. It's a well defined data model. There are Git-related projects like gui tools, for example, with the Eclipse IDE. And if you come from the Windows world people are used to the TortoiseSVN so there is TortoiseGit. Those people were saying we want Git but we are Windows developers and don't want the command line.
Also, the Git Web front-end came from the developer ecosystem and into the main Git tree.