Having the kernel as an anchor customer definitely helped, but there's also the reason that Linus wrote git in the first place, and that's that every other competitor was horrendously slow by comparison.

git, mercurial, and bazaar were all released at pretty much the same time (within weeks of each other in March/April 2005). AFAIK all in response to the whole Bitkeeper situation at the time.

I don't think performance was the main motivator; from what I recall it was mostly that Linus felt that the subversion model was "completely broken" and that there weren't any good distributed "bitkeeper-like" tools out there (and then, suddenly, there were three).

Linus was looking at monotone as an alternative to BitKeeper, but in his words "performance was so horrendously bad that [he] tried it for a day and realized [he] cannot use it": https://youtu.be/4XpnKHJAok8?t=711

Mercurial wasn't (at least for the projects I used it for).

It was very noticeably slower on all but the smallest projects. I started with it but switched to Git later for some open source work and that was one of the first impressions I had.

According to Facebook Mercurial was faster for them, but that was in 2014 and they had to put work in to actually make it fast. Their use case is rather outside the mainstream of course.

"When we first started working on Mercurial, we found that it was slower than Git in several notable areas. To narrow this performance gap, we’ve contributed over 500 patches to Mercurial over the last year and a half."

https://engineering.fb.com/2014/01/07/core-data/scaling-merc...

Personally I can't recall any serious performance difference after I switched from mercurial (which included some large-ish repos) to git, but it's been quite a few years ago and perhaps I just forgot.

Yeah, I tried it circa 2007 or 2008 so I’d easily believe that was significantly improved by 2014.

Torvalds.

Git is very much "here are tools, do what they want with them". There are no safety scissors included and the user must understand the problem to solve it. And the tools themselves are getting better over time, but you still need to understand what exactly you're doing, there is not much DWIM there and not that many shortcuts and no undo button.

Like the one I use semi often (aliased to re) is "git reset HEAD~1". If you read the Git book, you know what reset does, you know that HEAD is where you currently are, and you know that "~1" means "commit before". So you tell git to reset current tree to commit before the one you're currently on (essentially "undo commit").

Actually, having "git undo" to "revert whatever I just done, regardless of what it was" and "--explain" ("tell me what I am about to do") would probably help a lot...

0. Git is fast

0.5. it doesn't get in the way of getting things done (at least most of the time)

1. Git was faster than mercurial and bazar, eventually mercurial became fast but at that point it was too late 2. Git had a better svn backend, you could try git and get benefits from it even if your company used svn 3. Git did a lot of things that other dvcs didn't do (rebases, partial commits, history edits, local branches)

A lot of the UI simplicity of other tools rests on not doing (3). For example, OP awards negative points for rebase but as far as I am concerned I won't even consider using a UI that doesn't support rebase.