Sorry about the design comment, I just don't know what else to say. It's a really poor design for an SCM system. As an SCM person, I'm horrified at the Git de

Sorry about the design comment, I just don't know what else to say. It's a really poor design for an SCM system. As an SCM person, I'm horrified at the Git design. No file history? No file object? No file rename history? You guess at renames? Say what? If I were teaching a class on SCM and someone turned in Git as a class project I'd flunk them. It's fine if what you want is a compressed tarball server, that's the essence of what it is and exactly what Linus wanted. From that point of view the design is brilliant. From an SCM point of view it is very lacking. As for fast, Git is fast until it is not. See the Facebook benchmarking Git thread, it was posted here. Git commit and pull performance don't scale up at all. Git is very fast when everything fits in memory. It's horrible when things don't fit in memory. Remember, it names everything by hash, doing that is neat from a math point of view, it sucks from a disk point of view, even an SSD point of view. Finally, "optimize for the common case" I think is a bit off the mark here. Linus wasn't optimizing for performance, he was optimizing for ease of implementation. he simply doesn't care about the history. If he could have figured out a way to have a sliding window of history that was just enough to merge every old repo out there, I suspect he would have done that. To him, history is baggage, he just cares about the tip. SCM people care about all the history, it's all useful at some point. The goal is to record all of that, efficiently, so that when someone needs it, they have it. The video is just showing that we got the efficient part done.