{"thread":{"id":"6228","subject":"[PATCH] [gitweb] Blame \"linenr\" link jumps to previous state at \"orig_lineno\"","startedAt":"2007-01-05T02:37:45Z","lastAt":"2007-01-05T22:56:16Z","messageCount":3,"participants":["Luben Tuikov","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"30852","messageId":"605150.6351.qm@web31807.mail.mud.yahoo.com","threadId":"6228","inReplyTo":null,"subject":"[PATCH] [gitweb] Blame \"linenr\" link jumps to previous state at \"orig_lineno\"","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-05T02:37:45Z","receivedAt":"2007-01-05T02:37:45Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"Blame currently displays the commit id which introduced a\nblock of one or more lines, the line numbers wrt the current\nlisting of the file and the file's line contents.\n\nThe commit id displayed is hyperlinked to the commit.\n\nCurrently the linenr links are hyperlinked to the same\ncommit id displayed to the left, which is _no_ different\nthan the block of lines displayed, since it is the _same\ncommit_ that is hyperlinked. And thus clicking on it leads\nto the same state of the file for that chunk of\nlines. I.e. data mining is not currently possible with\ngitweb given a chunk of lines introduced by a commit.\n\nThis patch makes such data mining possible.\n\nThe line numbers are now hyperlinked to the parent of the\ncommit id of the block of lines. Furthermore they are\nlinked to the line where that block was introduced.\n\nThus clicking on a linenr link will show you the file's\nline(s) state prior to the commit id you were viewing.\n\nSo clicking continually on a linenr link shows you how this\nline and its line number changed over time, leading to the\ninitial commit where it was first introduced.\n\nSigned-off-by: Luben Tuikov \n---\n gitweb/gitweb.perl | 7 ++++++-\n 1 files changed, 6 insertions(+), 1 deletions(-)\n\nA quick show-and-tell of this patch is after applying it, open\n\"blame\" on a file, click on a linenr link of a block which\nhas only a single line changed -- the diff between what\nyou're seeing now and before is at least that line. This you can\ndata-mine with gitweb back to where the line was introduced. Similar\nargument applies to blocks of more than one line.\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex ac602ae..c87c61d 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -3208,9 +3208,14 @@ HTML\n \t\t\t\t esc_html($rev));\n \t\t\tprint \"\\n\";\n \t\t}\n+\t\topen (my $dd, \"-|\", git_cmd(), \"rev-parse\", \"$full_rev^\")\n+\t\t\tor die_error(\"could not open git-rev-parse\");\n+\t\tmy $parent_commit = <$dd>;\n+\t\tclose $dd;\n+\t\tchomp($parent_commit);\n \t\tmy $blamed = href(action => 'blame',\n \t\t\t\t file_name => $meta->{'filename'},\n-\t\t\t\t hash_base => $full_rev);\n+\t\t\t\t hash_base => $parent_commit);\n \t\tprint \"\";\n \t\tprint $cgi->a({ -href => \"$blamed#l$orig_lineno\",\n \t\t\t\t-id => \"l$lineno\",\n-- \n1.5.0.rc0.g90e5\n"},{"id":"30859","messageId":"7vk602jfo7.fsf@assigned-by-dhcp.cox.net","threadId":"6228","inReplyTo":"605150.6351.qm@web31807.mail.mud.yahoo.com","subject":"Re: [PATCH] [gitweb] Blame \"linenr\" link jumps to previous state at \"orig_lineno\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T03:50:00Z","receivedAt":"2007-01-05T03:50:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> A quick show-and-tell of this patch is after applying it, open\n> \"blame\" on a file, click on a linenr link of a block which\n> has only a single line changed -- the diff between what\n> you're seeing now and before is at least that line. This you can\n> data-mine with gitweb back to where the line was introduced. Similar\n> argument applies to blocks of more than one line.\n\nOne non-question and one question:\n\n - This favors the first parent, which is obviously the right\n thing for most of the time. I wonder what happens to a\n merge, though, but I realize that a line attributed to a\n merge is even rarer, and such a line is introduced by the\n \"evil merge\".\n\n - I wonder if the line number is correct for the parent\n commit. How well does this work when you clicked a line that\n was added at the end of the file, where the $orig_lineno goes\n beyond the whole file in the parent?\n"},{"id":"30919","messageId":"46370.61489.qm@web31814.mail.mud.yahoo.com","threadId":"6228","inReplyTo":"7vk602jfo7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] [gitweb] Blame \"linenr\" link jumps to previous state at \"orig_lineno\"","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-05T22:56:16Z","receivedAt":"2007-01-05T22:56:16Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Luben Tuikov writes:\n> \n> > A quick show-and-tell of this patch is after applying it, open\n> > \"blame\" on a file, click on a linenr link of a block which\n> > has only a single line changed -- the diff between what\n> > you're seeing now and before is at least that line. This you can\n> > data-mine with gitweb back to where the line was introduced. Similar\n> > argument applies to blocks of more than one line.\n> \n> One non-question and one question:\n> \n> - This favors the first parent, which is obviously the right\n> thing for most of the time. I wonder what happens to a\n> merge, though, but I realize that a line attributed to a\n> merge is even rarer, and such a line is introduced by the\n> \"evil merge\".\n> \n> - I wonder if the line number is correct for the parent\n> commit. How well does this work when you clicked a line that\n> was added at the end of the file, where the $orig_lineno goes\n> beyond the whole file in the parent?\n\nIt displayed the whole file, since the previous state of the\nfile I was looking at was short. In effect for the case in\npoint it displays the bottom of the file.\n\nIf you remember, this had been my \"white whale\" for about a\nyear and a half now. I accidentally \"got it\" while using\ngit-blame from shell prompt.\n\nI think it's a worthwhile thing to have in gitweb.\n\n Luben\n"}]}