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