Junio C Hamano <junkio@cox.net> writes: > Ren
Ha!, didn't think of that. I still like it more without a pager even if run on a terminal, because then you can *see* that it's really incremental (without needing to unset PAGER). I'm a non-believer. ;-) Ren
[PATCH] git blame --progress With --progress option, the command shows a fairly useless but amusing eye-candy while making the user wait. Signed-off-by: Junio C Hamano <junkio@cox.net> --- Ren
are you sure that you want to hard code the escape sequence? I guess the=
correct way would be to query terminfo.
cheers
simon
--=20
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low =E2=82=AC=E2=82=AC=E2=82=AC NOW!1 +++=
Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
It is not only amusing - it also gives the user a visual information (not precise, but interesting) about something happening, how fast is it happening and how long to wait. I like it, even though I seldom use git-blame myself, it's the kind of nice thing you have a fond memories afterwards. Like the ascii graphics :) -
Looks nice :) It makes it much more comfortable to wait for the real output. Perhaps there should be a config option to enable the eye-candy when git-blame is run on a terminal (e.g. (configoption && stdout is a tty && stderr is a tty) || --progress)? Typing --progress is annoying. I also noticed that git-blame with --progress is slowed down a bit by the terminal here; the output on stderr was ~400kb. -
Easy, that was not a serious patch meant for inclusion. If somebody wants to polish it up and re-submit that is fine by me. It might be interesting to add colors, make it less dependent on ANSI terminal control, and handle half-dots more intelligently. -
Nicely done, I like it. Well, then again, I used to watch the progress of filesystem defragmentors as a kid. Ahem. :-P The problem here is, of course, that we don't know how beforehand much work needs to be done. The indicator could be full of stars long before the start of history is reached. This could be helped somewhat by having three states instead of two: unblamed (.), blamed (o) and just-now-blamed (*). Each time new stars are written you'd demote the other stars in the field to o's. This way you'll at least see something moving until the end, no matter how often blame is pushed further down for already blamed lines. This increases terminal bandwidth usage and on-screen activity, but not necessarily the usefulness of this thing. :) Ren
On Mon, 29 Jan 2007, Ren
Ren
