On Sat, 27 Jan 2007, Linus Torvalds wrote: > > Quoth Simon 'corecode' Schubert: > > git log kdelibs/README takes 1:18. One minute, eighteen seconds. > > git rev-list and git blame take roughly the same time. Btw, why do people even think this is "slow"? Yeah, we should speed it up, just because I think having that large a repo will make it more obvious what we can do even better. No question about that. But I actually think that it's perfectly ok for "whole-history" operations to be slow. If you want the whole history of a big repository, you shouldn't expect it to be totally fast. And you should NOT expect the history for "one file" to be any faster than the history for "the whole repo". Because if you do, you have totally missed the whole point of git. It's not a "file tracker". It's a *content* tracker. A file doesn't have history. So what you're basically saying is that getting the whole history of KDE takes just over a minute. That's pretty damned *fast*. And yes, we can make it faster still. The operations that git has been optimized for is that the size of the history shouldn't affect *new* stuff. Basically, asking for "git log --since=1.week.ago" should be constant-time, regardless of how big the history is (well, it obviously depends on how many changes there have been in the last week, but the point is that it shouldn't get slower over time). And the git log output should "stream", so that you can do git log ..randomfile.. and you'll always get speedy access to the stuff that happened recently, and we should *never* have to do the whole history just to get the recent changes. That's why "git blame" is so horrible. It's fundamentally an operation that depends on "whole history" and thus cannot scale. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html