Re: git annotate runs out of memory

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Dec 11, 2007, 21:34 UTC
Message-ID: <alpine.LFD.0.9999.0712111323270.25032@woody.linux-foundation.org>
In-Reply-To: <4aca3dc20712111314wf4525l790120dce29a9bc5@mail.gmail.com>

On Tue, 11 Dec 2007, Daniel Berlin wrote:

Show 6 quoted lines

> 
> 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