3 ms·

As the original BitKeeper guy, the Git "design" is painful. I can tell you this, if Git was as good or better than BK, we would have folded up shop years ago.

As the original BitKeeper guy, the Git "design" is painful. I can tell you this, if Git was as good or better than BK, we would have folded up shop years ago. We kept going (and open sourced BK) so people could see how a decent SCM works. The fact that Git has no per file history data structure, no actual revisioning of renames, blame is insanely slow (see below for a demo), etc. Yeah, Git is really really popular, it won, no question. But man, did the world get screwed because of that. At this point I'm well on my way to being retired and playing with tractors, but I'd love it if Git ripped off everything useful in BK. I don't see it happening, Linus is proud of his "design", it's pretty entrenched. At least with BK out there as open source, you can fast-import your git tree, play around and see what the world could have been like. Oh, yeah, the blame demo. Git's file format isn't a file format, it's a repository format. With no formal file object, Git has to paw through the entire history to get the annotations for a single file. Most of the time you don't care but if you want to be responsive to bug reports, support requests, being able to figure out who changed what in a file is really helpful. So we benchmarked our blame implementation against Git's blame implementation, here's a little video about it: http://www.mcvoy.com/lm/bkdocs/blame.ogv http://www.mcvoy.com/lm/bkdocs/blame.ogv It's pretty hilarious IMHO.

emmelaich 10y ago
Considering how fast git is compared to everything else for common operations, I'm quite happy for `blame` to be slow. Optimise for the common case is standard engineering practice as I'm sure you know. (btw putting design in quotes is a bit rude; as a fan of yours it pains me a little to say this)
- luckydude 10y ago
  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.
- iainmerrick 10y ago
  Personally I would really love it if "git blame" were both fast and reliable. When working with other people's code I constantly look at file version history to figure out why things are the way they are. Unfortunately, big merges and renamings tend to break the history in Git.
  - luckydude 10y ago
    Renames break history in Git. Yup, that movie I linked to was not looking for renames and Git was still 1000x slower than BitKeeper. The default on blame in Git is to not look for renames because doing so is so slow. It's a non-issue in BitKeeper, the pathname of an object is an attribute of the object, just like the contents. It's exactly like a file system, we have an inode that is a unique name for the file, where it lives can vary from delta to delta, BitKeeper doesn't care. "Big merges" break history in Git. Not in BitKeeper, BK passes changes by reference not by value. What that means is suppose you have 3 users, A, B, and C. And you have a file with 1000 lines of code. A & B clone that repo and have identical versions of the file. A changes the top 501 lines, B changes the bottom 500 lines. Now C clones A and pulls B. In the merge, C has pick between A's line 501 and B's line 501 but the other lines are merged unchanged. In most naive systems, it will look like C wrote either the top 501 lines or the bottom 500 lines when you run blame. That's what I mean by pass by value, the merged lines are a copy. In BitKeeper, the unchanged merged lines are passed by reference, they are in the history exactly once. Only the line where it was merged (changed in the merge) will show up as belonging to C. You'd be amazed at how long it takes people to trust this. They are so used to pass by value semantics (and hate them because now a bunch code done by someone else appears to be done by C and C gets stuck with the bugs).
    - iainmerrick 10y ago
      OK, you got me interested. "brew install bitkeeper" worked so I might give it a try! Is there anything like Github or Bitbucket that supports BK? If there were a service to easily host BK repos, and especially if you could easily make it readable via Git, that could be pretty compelling. (Edit to add: http://bkbits.net http://bkbits.net maybe?)

emmelaich 10y ago

Considering how fast git is compared to everything else for common operations, I'm quite happy for `blame` to be slow. Optimise for the common case is standard engineering practice as I'm sure you know. (btw putting design in quotes is a bit rude; as a fan of yours it pains me a little to say this)

luckydude 10y ago
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.
iainmerrick 10y ago
Personally I would really love it if "git blame" were both fast and reliable. When working with other people's code I constantly look at file version history to figure out why things are the way they are. Unfortunately, big merges and renamings tend to break the history in Git.
- luckydude 10y ago
  Renames break history in Git. Yup, that movie I linked to was not looking for renames and Git was still 1000x slower than BitKeeper. The default on blame in Git is to not look for renames because doing so is so slow. It's a non-issue in BitKeeper, the pathname of an object is an attribute of the object, just like the contents. It's exactly like a file system, we have an inode that is a unique name for the file, where it lives can vary from delta to delta, BitKeeper doesn't care. "Big merges" break history in Git. Not in BitKeeper, BK passes changes by reference not by value. What that means is suppose you have 3 users, A, B, and C. And you have a file with 1000 lines of code. A & B clone that repo and have identical versions of the file. A changes the top 501 lines, B changes the bottom 500 lines. Now C clones A and pulls B. In the merge, C has pick between A's line 501 and B's line 501 but the other lines are merged unchanged. In most naive systems, it will look like C wrote either the top 501 lines or the bottom 500 lines when you run blame. That's what I mean by pass by value, the merged lines are a copy. In BitKeeper, the unchanged merged lines are passed by reference, they are in the history exactly once. Only the line where it was merged (changed in the merge) will show up as belonging to C. You'd be amazed at how long it takes people to trust this. They are so used to pass by value semantics (and hate them because now a bunch code done by someone else appears to be done by C and C gets stuck with the bugs).
  - iainmerrick 10y ago
    OK, you got me interested. "brew install bitkeeper" worked so I might give it a try! Is there anything like Github or Bitbucket that supports BK? If there were a service to easily host BK repos, and especially if you could easily make it readable via Git, that could be pretty compelling. (Edit to add: http://bkbits.net http://bkbits.net maybe?)