Re: More precise tag following

On Sat, 27 Jan 2007, Linus Torvalds wrote:

Quoth Simon 'corecode' Schubert:

quoted

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