René Scharfe <rene.scharfe@xxxxxxxxxxxxxx> writes: > 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 ;-). - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html