Re: git annotate runs out of memory

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 11, 2007, 20:14 UTC
Message-ID: <m3bq8xrntc.fsf@roke.D-201>
In-Reply-To: <74ED838F-4966-42A9-BC8A-906FD0B4B46F@midwinter.com>

Steven Grimm <koreth@midwinter.com> writes:

> On Dec 11, 2007, at 10:40 AM, Linus Torvalds wrote:

Show 18 quoted lines

> > To git, "git annotate" is just about the *last* thing you ever want
> > to do.
> > It's not a common operation, it's a "last resort" operation. In git,
> > the
> > whole workflow is designed for "git log -p <pathnamepattern>" rather
> > than
> > annotate/blame.
> 
> My use of "git blame" is perhaps not typical, but I use it fairly
> often when I'm looking at a part of my company's code base that I'm
> not terribly familiar with. I've found it's the fastest way to figure
> out who to go ask about a particular block of code that I think is
> responsible for a bug, or more commonly, who to ask to review a change
> I'm making.
> 
> "git log" is too coarse-grained to be useful for that purpose; it
> usually doesn't tell me which of the 500 revisions to the file I'm
> looking at introduced the actual line of code I want to change.

There is always "pickaxe" search, i.e. 
  $ git log -p -S'<string>' -- <file or pathspec>
which can be used instead of blame (perhaps with --follow).

And you can limit blame to the interesting region of file, and to interesting (important) range of revisions.

[about blame cache]

"git gui blame" uses incremental blame; if only it accepted range (file fragment) limiting, and if "reblame" (blame --reference=<rev>, blaming incrementally only lines which changed wrt. given revision) was implemented.

BTW. qgit actually does blame using it's own "multiple files bottom-up blame" code (it would be nice to have it in core-git if possible, hint, hint), and does some caching, although I'm not sure if blame info also. You should try it, I think.

-- 
Jakub Narebski
Poland
ShadeHawk on #git