emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Progress report on git-blame


From: Óscar Fuentes
Subject: Re: Progress report on git-blame
Date: Sat, 25 Jan 2014 19:52:10 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Lars Ingebrigtsen <address@hidden> writes:

[snip]

> So I'm usually just interested in a screenful of lines.

Same here.

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

Hmmm...

$ # ran this twice, for warming the cache:
$ time git blame -- src/xdisp.c > /dev/null

real    2m48.232s
user    2m45.233s
sys     0m2.829s


$ # `blame' on 20 lines starting at line 1000:
$ time git blame -L 1000,+20 -- src/xdisp.c > /dev/null

real    0m10.861s
user    0m10.296s
sys     0m0.547s


:-)


Some random data points:

$ time git blame -L 1000,+100 -- src/xdisp.c > /dev/null

real    0m11.034s
user    0m10.417s
sys     0m0.599s


$ time git blame -L 1000,+1000 -- src/xdisp.c > /dev/null

real    0m15.089s
user    0m14.297s
sys     0m0.767s


$ time git blame -L 1000,+10000 -- src/xdisp.c > /dev/null

real    1m5.144s
user    1m3.555s
sys     0m1.502s


It seems that there is not a lot of a difference among blaming 20 lines
and blaming 1000.

AFAIK current `blame' functionality on VC (and on git-blame.el) is based
on working on the whole file, so implementing partial blame would
require significant changes on how VC renders the `blame' output.

However, the speed gain is so much that IMO it is worth using M-x
compile "git blame -L ...." on the simple scenario you described.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]