Re: [PATCH] git blame --progress

René Scharfe [off-list ref] writes:

Junio C Hamano schrieb:

quoted

[PATCH] git blame --progress

With  --progress option, the command shows a fairly useless but 
amusing eye-candy while making the user wait.

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. :)

I do not know if this is working as you intended.

If somebody wants to really do this, the first clean-up to be
done is to remove the two loops that goes back and forward to
find the continguous guilty range.  That was done only because I
was lazy and did not want to count the boundary to deal with a
half-dot problem (a displayed column on the screen can represent
N lines -- what happens when the blame entry whose origin is now
known covers only partially?  You need to either draw it as a
half-done, or you make sure to paint it only when all of the N
lines are blamed).  The output from my original will repaint the
whole thing at the end of the blame because at that point
spot_lo and spot_hi would cover the entire range -- which shows
how lazy I am ;-).