Re: [PATCH] git blame --progress

Previous thread: [PATCH] Documentation/config.txt: Fix documentation of colour config tweaks. by Mark Wooding on Sunday, January 28, 2007 - 8:17 am. (2 messages)

Next thread: [PATCH] Replace perl code with pure shell code by Simon 'corecode' Schubert on Monday, January 29, 2007 - 1:09 am. (9 messages)
From: Junio C Hamano
Date: Sunday, January 28, 2007 - 12:09 pm

From: Junio C Hamano
Date: Sunday, January 28, 2007 - 12:14 pm

Junio C Hamano <junkio@cox.net> writes:

> Ren
From: rene.scharfe
Date: Sunday, January 28, 2007 - 5:32 pm

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
From: Junio C Hamano
Date: Sunday, January 28, 2007 - 7:35 pm

[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
From: Simon 'corecode' Schubert
Date: Monday, January 29, 2007 - 12:00 am

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   / \

From: Alex Riesen
Date: Monday, January 29, 2007 - 9:54 am

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

From: Matthias Lederhofer
Date: Monday, January 29, 2007 - 11:12 am

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

From: Junio C Hamano
Date: Monday, January 29, 2007 - 12:06 pm

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.



-

From: rene.scharfe
Date: Monday, January 29, 2007 - 12:59 pm

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
From: Linus Torvalds
Date: Monday, January 29, 2007 - 1:24 pm

On Mon, 29 Jan 2007, Ren
From: Junio C Hamano
Date: Monday, January 29, 2007 - 6:53 pm

Previous thread: [PATCH] Documentation/config.txt: Fix documentation of colour config tweaks. by Mark Wooding on Sunday, January 28, 2007 - 8:17 am. (2 messages)

Next thread: [PATCH] Replace perl code with pure shell code by Simon 'corecode' Schubert on Monday, January 29, 2007 - 1:09 am. (9 messages)