Re: blameview and file line number

Junio C Hamano [off-list ref] wrote:

As Linus mentioned, the screen real estate is already wasted by
too much metainfomation.  Although I do not care too much about
the UI issue in it since this is only a sample program, showing
the line number for each line in the final image ($lno) to waste
more space feels doubly wrong.

Actually including the final image line number is probably something
you want to do in a blame viewer.  When I rework git-gui's blame
UI I'm going to keep the original line number column, but ditch
everything else into some sort of cursor-following-floating window
(Linus' idea).

The reason is, I'll be looking at a line of code in a 5000 line
source file in Eclipse (or vi!) and want to know how it came to be.
I'll go open a blame, but now I have 5000 lines to scan through.

If there's line numbers and a scrollbar, I can binary search to
it relatively quickly.  If there's a text search function, sure I
could try to enter part of the symbol to match, but at that point
I might as well just enter the line number to jump to, especially
if the symbol appears a few times in that file.

So yes, the -L option to git-blame is *very* handy on the command
line.  But I think you already knew that...

I realize that git-gui's blame feature won't be used very often
by the really hard-core developers on this list (you know who you
are) as the command line is simply faster, easier to use, and more
powerful.  Most of the features in git-gui are being created for
people who are a tad bit afraid of a command line and prefer to
point their way through their life with a small rodent shaped device.
Those folks need something like a -L that they can make use of.

By the way, telling git-gui to annotate revision.h with the
attached patch was fun to watch.

Yes, especially with its current technicolor interface.  :-)

I just had to go run this, and aside from the rather horrible blame
interface in git-gui, I'm seeing that git-blame is producing data
faster than git-gui can really process it.  This causes the UI to
flash through huge batches of updates.  Probably would be much more
interesting if I disabled the fileevent handler for a few hundred
ms to let the UI catch up.  :-)

-- 
Shawn.