Re: git annotate runs out of memory

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 11 Dec 2007, Daniel Berlin wrote:
> 
> You theroetically can generate blame info from SVN/GIT's block deltas,
> but you of course, have the problem GIT does, which is that the delta
> is not meant to represent the actual changes that occurred, but
> instead, the smallest way to reconstruct data x from data y.
> This only sometimes has any relation to how the file actually changed

Exactly. Git objects in themselves have no history or relationships, and 
being a delta against another object means nothing at all except for the 
fact that the data seems to resemble that other object (which has a 
_correlation_ with being related, but nothign more).

Anyway, I think the git annotate memory usage was simpyl just a real bug 
that nobody had noticed before because the memory leak wasn't all that 
noticeable with smaller files and/or less deep histories. Can'you verify 
that it works for you with the patch I sent out?

With that fix, I could even run 

	git blame -C gcc/ChangeLog-2000

to see the blame machinery work past the strange "combine many different 
changelogs into year-based ones" commit. Now, I cannot honestly claim that 
it was really *usable* (it did take three minutes to run!), but sometimes 
those three minutes of CPU time may be worth it, if it shows the real 
historical context it came from. 

In the case of the ChangeLog-2000 file, all the original lines obviously 
came from older versions of a file called "gcc/ChangeLog", so the end 
result doesn't really show what an involved situation it was to track the 
sources back through not just renames, but actually file splits and 
merges. Sad, but once you know what it did it's still a bit cool to see 
that it worked ;)

			Linus