Re: [PATCH] git blame --progress

From: Junio C Hamano <junkio@cox.net>
Date: Jan 30, 2007, 01:53 UTC
Message-ID: <7vlkjl700g.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <45BE520A.6050906@lsrfire.ath.cx>

René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

Show 21 quoted lines

> Junio C Hamano schrieb:
>> [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 ;-).