Re: Progress report on git-blame

[David Kastrup]

Lars Ingebrigtsen <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Apart from trying to bully up general git performance and from trying to
>> get the unpacking to cache smarter, it would also be feasible to add a
>> "fast track" interface to git blame --interactive where Emacs sends
>> information about "currently viewed material corresponds to lines
>> xxx...yyy in the file" to the running git process which is used for
>> prioritizing the outstanding work.
>
> That sounds quite useful.  My common bug fixing use case is that I find
> a function (or a bit of a function) that I think has a bug, and then I
> `C-x v g' to find out who "who wrote this crap anyway!!!" (it usually
> turns out to be myself), and then I try to see whether any of the lines
> are suspiciously new and may have introduced a new bug.
>
> So I'm usually just interested in a screenful of lines.  If we could
> have a version of `C-x v g' that only does "blame" for the current
> region, for instance, that would certainly fit my use case.

It's worth noting that you already _can_ ask "git blame" for just a
region.  However, implementing this into a general update strategy will
mean that you'll usually have one git blame --incremental running for
the big picture, and one-shot git-blame instances for producing the
missing parts from the currently exposed area (probably sigstopping the
"big" process while the small updates run).  That means parallel work
that will ultimately go wasted.  It does have the advantage of working
with the currently available binaries.  A dynamically adjusted search
seems nicer.

-- 
David Kastrup