>>> Jakub Narebski <jnareb@xxxxxxxxx> schrieb am 03.04.2017 um 17:16 in Nachricht <0ccc5cab-26b7-4b02-b964-452b61e92579@xxxxxxxxx>: > 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. I was thinking similar: The pain vc-annotate obviously should work without those "-C" options, and with prefix argument (C-u <num> in Emacs) it could start looking for copied stuff. HMO... Worse than no progress reporting is the inability to kill the process (if you run out of patience) with C-g (that stops most commands in Emacs). > > 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). I confess taht is still use RCS from time to time, and I prefer the higher-level Emacs commands ;-) Regards, Ulrich