If you’re a developer who has been putting off understanding how Git works under the hood, then this guide is for you. For those of us who get by with only knowing a few commands, Git can be a little mystifying:
Well, not quite. He put together a working proof of concept in about two weeks, true, but the git of today is only conceptually related to that first code.
The “other solution he was using” is a bit more convoluted. Linus initially didn’t use any source control because none of them fit his workflow on Linux. He was acting as the final clearinghouse for patches sent from all over the world and would’ve needed all the complexity of Git that today we take for granted. Except that the era’s source control systems sucked. Subversion was one of the better ones and it was completely unfit for complex flows. Others were even worse.
At some point he was talked into using a new system called BitKeeper which promised to be better than everything else. And it kinda was, but it also brought lots of friction in the community. For example it was proprietary and people didn’t feel right about Linux relying on proprietary infrastructure. Then there was a kerfuffle between the owner of BitKeeper and some members of the community about the way he was licensing the technology and keeping back features, so they went and reverse engineered the protocol and he got mad and so on and so forth.
Eventually Linux had enough of it, but now that he’d used a source control that actually helped he didn’t want to go back to nothing. So he said screw this and designed Git. His core design principle was “take everything Subversion does and do the exact opposite”. The name “git” was apparently a self-deprecating joke, as in “i’m a git for even attempting this”.
Well, not quite. He put together a working proof of concept in about two weeks, true, but the git of today is only conceptually related to that first code.
The “other solution he was using” is a bit more convoluted. Linus initially didn’t use any source control because none of them fit his workflow on Linux. He was acting as the final clearinghouse for patches sent from all over the world and would’ve needed all the complexity of Git that today we take for granted. Except that the era’s source control systems sucked. Subversion was one of the better ones and it was completely unfit for complex flows. Others were even worse.
At some point he was talked into using a new system called BitKeeper which promised to be better than everything else. And it kinda was, but it also brought lots of friction in the community. For example it was proprietary and people didn’t feel right about Linux relying on proprietary infrastructure. Then there was a kerfuffle between the owner of BitKeeper and some members of the community about the way he was licensing the technology and keeping back features, so they went and reverse engineered the protocol and he got mad and so on and so forth.
Eventually Linux had enough of it, but now that he’d used a source control that actually helped he didn’t want to go back to nothing. So he said screw this and designed Git. His core design principle was “take everything Subversion does and do the exact opposite”. The name “git” was apparently a self-deprecating joke, as in “i’m a git for even attempting this”.