Re: Terrible bad performance for it blame --date=iso -C
- From
SZEDER Gábor <szeder.dev@gmail.com>
- Date
- Apr 3, 2017, 10:56 UTC
- Message-ID
- <20170403105641.16912-1-szeder.dev@gmail.com>
- In-Reply-To
- <58E1F239020000A100025732@gwsmtp1.uni-regensburg.de>
Show 5 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.