Steven Grimm <koreth@xxxxxxxxxxxxx> writes: > On Dec 11, 2007, at 10:40 AM, Linus Torvalds wrote: > > 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 - 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
