Re: blameview and file line number

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jan 30, 2007, 15:48 UTC
Message-ID: <20070130154852.GA25950@spearce.org>
In-Reply-To: <7vd54w23zh.fsf@assigned-by-dhcp.cox.net>

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

Show 5 quoted lines

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