Re: More precise tag following

Theodore Tso [off-list ref] wrote:

On Mon, Jan 29, 2007 at 08:24:52AM -0800, Linus Torvalds wrote:

quoted

Anyway, all of these issues makes me suspect that the proper blame 
interface is to basically *hide* the blame almost entirely, in order to 
make the important parts much more visible, and in order to encourage 
people to start looking for the piece of code that they are actually 
interested in.

One approach which might work is where you hover your mouse over a
line, and it pops up a tiny window with the blame information if the
mouse remains stationary for more than a second or two.

Another thing which would be really useful is where the lines that
have been changed in the last n commits (where n is probably between
3-5) are highlighted using different colors.  That way you can see
what was changed recently, which is often what you are most interested
in.  (As in, what changed recently that might have caused this file to
get all screwed up?)

In case you are interested, I've tweaked the display of annotation
data in git-gui.  The latest version lets you run blame right from
the command line:

	git-gui blame master revision.c

Clicking on a line colors that line and all lines which are blamed
on the same commit as yellow; the commit before it (ancestor)
is colored blue and the commit after it (descendant) is colored red.

The bottom part of the window is used to show the commit SHA-1,
author, committer and complete log message.  I have not yet added
navigating to the prior commit, or support for the new --contents
flag.

Because the data is now in the bottom pane (and not in columns),
the display is about 90 characters wide, instead of 180 or whatever
insane value it was.

-- 
Shawn.