From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <junkio@cox.net>
Cc: Aneesh Kumar <aneesh.kumar@gmail.com>, git@vger.kernel.org
Subject: Re: blameview and file line number
Date: Tue, 30 Jan 2007 10:48:52 -0500 [thread overview]
Message-ID: <20070130154852.GA25950@spearce.org> (raw)
In-Reply-To: <7vd54w23zh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> 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.
next prev parent reply other threads:[~2007-01-30 15:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-30 7:25 blameview and file line number Aneesh Kumar
2007-01-30 8:33 ` Junio C Hamano
2007-01-30 9:12 ` Aneesh Kumar
2007-01-30 10:39 ` Junio C Hamano
2007-01-30 15:48 ` Shawn O. Pearce [this message]
2007-01-30 14:06 ` Jeff King
2007-01-30 14:08 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070130154852.GA25950@spearce.org \
--to=spearce@spearce.org \
--cc=aneesh.kumar@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).