Re: Progress report on git-blame

["Óscar Fuentes" <ofv@wanadoo.es>]

David Kastrup <dak@gnu.org> writes:

>> It seems that there is not a lot of a difference among blaming 20 lines
>> and blaming 1000.
>
> It very much depends on _which_ lines.  Basically, lines forming a block
> sticking together when doing a unified diff are not all that expensive
> since they travel in a single data structure.  The worst are lots of
> small changes introduced in different branches.

I suspected some effect like that, so before posting I tried other file
segments and most of them required the same time as the one showed, with
the rest requiring less time (7s vs 11s)

>> AFAIK current `blame' functionality on VC (and on git-blame.el) is
>> based on working on the whole file,
>
> Sure?

Not, really, but almost. :-) It seems quite clear that vc-annotate just
displays the output of the underlying VC tool.

> If so, it maybe should at least be made to support git blame
> --incremental usefully.

Of course --incremental can also apply to a line-range blame. From
trying a couple of times it seems that the most recently changed lines
were annotated first, so for Lars' case of checking if some line on the
range was recently changed, he would have the relevant info sooner (but
if all the lines are old, he would have to wait until some line is
annotated to know the fact; in that case there is no significant time
again over non-incremental annotation, so speeding up `git blame' is
worthy in any case.)