W dniu 03.04.2017 o 12:56, SZEDER Gábor pisze: > Ulrich Windl wrote: >> 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
