threads / patch / 6228

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

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

## tl;dr

3 messages between Jan 5, 2007 and Jan 5, 2007. Diffs are folded; open one to read it.

replies: 2people: 2as markdown or json

Luben Tuikov· Jan 5, 2007, 02:37 UTC · lore

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.

Show changes to gitweb/gitweb.perl +6 −1

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

Junio C Hamano· Jan 5, 2007, 03:50 UTC · re: Luben Tuikov · lore

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

Luben Tuikov <ltuikov@yahoo.com> writes:

Show 6 quoted lines

> 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?

Luben Tuikov· Jan 5, 2007, 22:56 UTC · re: Junio C Hamano · lore

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

--- Junio C Hamano <junkio@cox.net> wrote:

Show 21 quoted lines

> 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