Git is an entirely appropriate tool for managing as something as large and complex as the Linux kernel, but I'm doing much simpler stuff, and Mercurial is simpler and has a much shallower learning curve. I'd recommend it unequivocally to teams of modest size working on average applications.

The state of git documentation is much better today than it was five or six years ago, so maybe its complexity is less of a big deal, but so far I've not encountered any issues with Mercurial that make me think "If only I was using git this would be easy!"

What I found with git was I had to maintain a fairly complex mental model of the current state of affairs, and because I'm not very intelligent that took quite a bit of effort. With Mercurial the model is much simpler, so I can spend more of my very limited attention on writing code. It's quite possible that I simply never took the time to learn git properly, but with Mercurial I didn't have to.

http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...

But we've never figured out how to make it work financially. If anyone has any ideas I'm all ears (though pointing at github and saying "do that" isn't an idea that I can execute).

BTW, BK used to be pretty darned close to open source, you got the source code under a funky license that said "don't take out the part that lets us make money". We stopped shipping the source when we learned that the very first thing that someone committed to the repo was taking out the part that let us make money.

Git has a large industry of value-add / support companies now. But no one commercial company can own or control the core. And that's one key reason why it's so popular and has such a large ecosystem around it. So to be like git, bitkeeper would have had to really give up central ownership and control. Commercial companies never do that unless they're going out of business anyway, they just can't.

Of course, he also didn't have as much to explain at that stage :)

[1] https://jwiegley.github.io/git-from-the-bottom-up/

    * He aches for the very best tool that will suit all his major  needs. 
    * He mentions getting the data structures right first, which is of prime importance. And no, it doesn't mean you start building TreeFactoryAdapter's.
    * He codes at the lowest level, in C (please don't whine about assembly), to maintain complete control over memory usage.

To borrow an overused cliché, the code was just the tip of the iceberg. The hidden body of the MVP was the design he had been thinking about for a while. But we, as external observers, can't really see or appreciate what was going on in his head as he planned this out. It doesn't feel like "real" work, which makes the small remaining part that does seem all that much more impressive. This is actually a real source of tension between certain programmers and managers: it's hard for managers to tell actual thinking apart from day-dreaming, so programmers just look lazy in their eyes.

Torvalds wrote about this himself in the interview:

> So I'd like to stress that while it really came together in just about ten days or so (at which point I did my first kernel commit using git), it wasn't like it was some kind of mad dash of coding. The actual amount of that early code is actually fairly small, it all depended on getting the basic ideas right. And that I had been mulling over for a while before the whole project started. I'd seen the problems others had. I'd seen what I wanted to avoid doing.

How do you achieve this level of productivity yourself?

Personally, I think the main quality you want, as I alluded earlier, is comfort. Get yourself to the point where you trust your tools (and yourself) enough to execute your ideas without apprehension. You want to build yourself up to the point where your tools—everything from your programming language to your editor to your libraries—don't get in the way. They should almost feel like extensions of you. Think about it like riding a bicycle or skiing where you start thinking exclusively about where you're going without being distracted by how. Ideally, you want to think about the problem you're solving and the abstraction you're building rather than the mundane details of how you convey this to the computer.

    > [...] nor have I ever heard systematic criticism of Github's methodology.

    > (a) make a real pull request, not the braindamaged crap that github
    >     does when you ask it to request a pull: real explanation, proper email
    >     addresses, proper shortlog, and proper diffstat.
    >
    > (b) since github identities are random, I expect the pull request to
    >     be a signed tag, so that I can verify the identity of the person in
    >     question.

All he seems to be asking for is that we take our time and do it properly. Makes all the sense in the world for a large, long-lived open source project like Linux. Imagine 20-year-old commit messages from FreeBSD would look like the ones we write today for, say, a npm module.

--- edit ---

Yeah ... nevermind. He explains it himself further down:

    > Btw, Joseph, you're a quality example of why I detest the github
    > interface. For some reason, github has attracted people who have zero
    > taste, don't care about commit logs, and can't be bothered.
    >
    > The fact that I have higher standards then makes people like you make
    > snarky comments, thinking that you are cool.
    >
    > You're a moron.
    >
    >                 Linus

Github doesn't scale at all for large projects. The kernel is averaging over 8 changes an hour, 24 hours a day. That rate of change can never be handled by doing pull requests and web site review. It only can work with email and review and scriptable processes.

If I need to use it I will learn it then. I don't think most people care as such.