Junio C Hamano <junkio@xxxxxxx> 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. - 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