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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.