Ever since gitweb on kernel.org was recently updated, I've been experiencing a
nasty bug -- It seems that it is no longer possible to view a shortlog from any
branch or head other than master.

For example:

http://www2.kernel.org/git/?p=linux/kernel/git/mkrufky/v4l-dvb-2.6.x.y.git

^^ this is a link to my v4l-dvb-2.6.x.y stable repository.  I have branched off
each kernel release to include all of the -stable release history.  You will
notice these in the 'heads' section near the bottom of the page.

If you click on the 2.6.16.y shortlog link:

http://www2.kernel.org/git/?p=linux/kernel/git/mkrufky/v4l-dvb-2.6.x.y.git;a=shortlog;...

gitweb displays the shortlog from the master branch, instead of the 2.6.16.y head.

However, if you click the "log" link:

http://www2.kernel.org/git/?p=linux/kernel/git/mkrufky/v4l-dvb-2.6.x.y.git;a=log;h=2.6...

Only then, does gitweb show us the correct history for that branch.

"tree" is also working properly -- it seems that "shortlog" is the only feature
affected by this bug.

In the previous vesion of gitweb installed on kernel.org, this feature did
indeed function properly.

Can this be fixed?  I often use gitweb to view changesets in developer trees
before those changesets get pulled into the master branch of a repository.  I
find this feature very helpful for reviewing changesets, and I'd like for it to
work again.

Thanks in advance,

Michael Krufky

-

[ message continues ]

This fixes typo in 190d7fdcf325bb444fa806f09ebbb403a4ae4ee6

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---

This corrects this bug.  When introducing parse_commits to shortlog,
there was typo in parse_commits arguments: it was $head instead of $hash.

 gitweb/gitweb.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2ead917..2179054 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4423,7 +4423,7 @@ sub git_shortlog {
 	}
 	my $refs = git_get_references();
 
-	my @commitlist = parse_commits($head, 101, (100 * $page));
+	my @commitlist = parse_commits($hash, 101, (100 * $page));
 
 	my $paging_nav = format_paging_nav('shortlog', $hash, $head, $page, (100 * ($page+1)));
 	my $next_link = '';
-- 
1.4.4.3

-

[ message continues ]

My change in 190d7fdcf325bb444fa806f09ebbb403a4ae4ee6 had a small bug
found by Michael Krufky which caused the passed in hash value to be
ignored, so shortlog would only show the HEAD revision.

Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---

Thanks for finding this Michael.  It' just a small bug introducted by a
recent change I made.  Including John 'Warthog9' so hopefully he can add
this to the version of gitweb which is hosted on kernel.org.

Robert


 gitweb/gitweb.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d845e91..2e94c2c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4423,7 +4423,7 @@ sub git_shortlog {
 	}
 	my $refs = git_get_references();
 
-	my @commitlist = parse_commits($head, 101, (100 * $page));
+	my @commitlist = parse_commits($hash, 101, (100 * $page));
 
 	my $paging_nav = format_paging_nav('shortlog', $hash, $head, $page, (100 * ($page+1)));
 	my $next_link = '';
-- 
t1.gaaaa
-

[ message continues ]

Robert,

Thank you for fixing this bug so quickly.  I've noticed that the gitweb
templates on kernel.org have changed at least once since you wrote this email to
me... (I can tell, based on the fact that the git:// link has moved from the
project column to a link labeled, "git" all the way to the right.)

Unfortunately, however, the bug that I had originally reported has not yet been
fixed on the kernel.org www server.  Either the patch in question hasn't yet
been applied to that installation, or it HAS in fact been applied, but doesn't
fix the problem as intended.

Do you know which of the above is true?

Thanks again,


-

[ message continues ]

Simple answer - it's sitting in my tree waiting for me to have enough
time to get back to gitweb.  There are several things in flight and I'm
not prepared to push them out in their current state.

So yes the problem is fixed, but it will probably be sometime this

-

[ message continues ]