git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

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