[PATCH] [gitweb] Blame "linenr" link jumps to previous state at "orig_lineno"

[PATCH] [gitweb] Blame "linenr" link jumps to previous state at "orig_lineno"

[Luben Tuikov]

Blame currently displays the commit id which introduced a
block of one or more lines, the line numbers wrt the current
listing of the file and the file's line contents.

The commit id displayed is hyperlinked to the commit.

Currently the linenr links are hyperlinked to the same
commit id displayed to the left, which is _no_ different
than the block of lines displayed, since it is the _same
commit_ that is hyperlinked.  And thus clicking on it leads
to the same state of the file for that chunk of
lines. I.e. data mining is not currently possible with
gitweb given a chunk of lines introduced by a commit.

This patch makes such data mining possible.

The line numbers are now hyperlinked to the parent of the
commit id of the block of lines.  Furthermore they are
linked to the line where that block was introduced.

Thus clicking on a linenr link will show you the file's
line(s) state prior to the commit id you were viewing.

So clicking continually on a linenr link shows you how this
line and its line number changed over time, leading to the
initial commit where it was first introduced.

Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
 gitweb/gitweb.perl |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

A quick show-and-tell of this patch is after applying it, open
"blame" on a file, click on a linenr link of a block which
has only a single line changed -- the diff between what
you're seeing now and before is at least that line.  This you can
data-mine with gitweb back to where the line was introduced.  Similar
argument applies to blocks of more than one line.

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ac602ae..c87c61d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3208,9 +3208,14 @@ HTML
 				      esc_html($rev));
 			print "</td>\n";
 		}
+		open (my $dd, "-|", git_cmd(), "rev-parse", "$full_rev^")
+			or die_error("could not open git-rev-parse");
+		my $parent_commit = <$dd>;
+		close $dd;
+		chomp($parent_commit);
 		my $blamed = href(action => 'blame',
 				  file_name => $meta->{'filename'},
-				  hash_base => $full_rev);
+				  hash_base => $parent_commit);
 		print "<td class=\"linenr\">";
 		print $cgi->a({ -href => "$blamed#l$orig_lineno",
 				-id => "l$lineno",
-- 
1.5.0.rc0.g90e5

Re: [PATCH] [gitweb] Blame "linenr" link jumps to previous state at "orig_lineno"

[Junio C Hamano]

Luben Tuikov <ltuikov@yahoo.com> writes:

> A quick show-and-tell of this patch is after applying it, open
> "blame" on a file, click on a linenr link of a block which
> has only a single line changed -- the diff between what
> you're seeing now and before is at least that line.  This you can
> data-mine with gitweb back to where the line was introduced.  Similar
> argument applies to blocks of more than one line.

One non-question and one question:

 - This favors the first parent, which is obviously the right
   thing for most of the time.  I wonder what happens to a
   merge, though, but I realize that a line attributed to a
   merge is even rarer, and such a line is introduced by the
   "evil merge".

 - I wonder if the line number is correct for the parent
   commit.  How well does this work when you clicked a line that
   was added at the end of the file, where the $orig_lineno goes
   beyond the whole file in the parent?

Re: [PATCH] [gitweb] Blame "linenr" link jumps to previous state at "orig_lineno"

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> > A quick show-and-tell of this patch is after applying it, open
> > "blame" on a file, click on a linenr link of a block which
> > has only a single line changed -- the diff between what
> > you're seeing now and before is at least that line.  This you can
> > data-mine with gitweb back to where the line was introduced.  Similar
> > argument applies to blocks of more than one line.
> 
> One non-question and one question:
> 
>  - This favors the first parent, which is obviously the right
>    thing for most of the time.  I wonder what happens to a
>    merge, though, but I realize that a line attributed to a
>    merge is even rarer, and such a line is introduced by the
>    "evil merge".
> 
>  - I wonder if the line number is correct for the parent
>    commit.  How well does this work when you clicked a line that
>    was added at the end of the file, where the $orig_lineno goes
>    beyond the whole file in the parent?

It displayed the whole file, since the previous state of the
file I was looking at was short.  In effect for the case in
point it displays the bottom of the file.

If you remember, this had been my "white whale" for about a
year and a half now.  I accidentally "got it" while using
git-blame from shell prompt.

I think it's a worthwhile thing to have in gitweb.

   Luben