Re: Terrible bad performance for it blame --date=iso -C

From: Jakub Narębski <jnareb@gmail.com>
Date: Apr 3, 2017, 15:16 UTC
Message-ID: <0ccc5cab-26b7-4b02-b964-452b61e92579@gmail.com>
In-Reply-To: <20170403105641.16912-1-szeder.dev@gmail.com>

W dniu 03.04.2017 o 12:56, SZEDER Gábor pisze:

> Ulrich Windl wrote:

Show 26 quoted lines

>> In the other case (for the user bored of waiting seeking for some
>> entertainment ;-)) a "-v (verbose) option could be useful.  Or at the
>> very least: If git is expecting that some operation will take (or
>> already did take) a lot of time, give some message explaining why it
>> is taking a lot of time, and maybe how to avoid that.
> 
> It already does so by default since v2.8.0, see aba37f495 (blame: add
> support for --[no-]progress option, 2015-12-12).
> 
>   $ time git blame sha1_file.c |wc -l
>   4026
>   
>   real    0m1.744s
>   user    0m1.672s
>   sys     0m0.068s
>   $ time git blame -C -C sha1_file.c |wc -l
>   Blaming lines: 100% (4026/4026), done.
>   4026
>   
>   real    0m3.832s
>   user    0m3.716s
>   sys     0m0.112s
> 
> However, after a short peek at that commit, it only displays progress
> by default when stderr is a terminal, which might not be the case when
> invoked from emacs.

Emacs (magit?) should use `git blame --porcelain`, and do its own progress report, just like 'git gui blame' and incremental blame mode of gitweb.

Actually... there already is git-blamed - Minor mode for incremental blame for Git, and mo-git-blame - An interactive, iterative 'git blame' mode for Emacs, both available on ELPA (Emacs Lisp Package Archive).

HTH

-- 
Jakub Narębski