Jakub Narebski <jnareb@xxxxxxxxx> writes:
> Gerrit Pape <pape@xxxxxxxxxxx> writes:
>
> > When viewing a gitweb repository commit log, the "next" link at the top
> > of the page works as expected, the "next" link on the bottom of the page
> > has a=search instead of a=log and thus fails to get you to the next
> > page. This commit replaces the bottom "next" link with the same links
> > as shown at the top of the page.
>
> > - print $cgi->a({-href => href(-replay=>1, page=>$page+1),
> > - -accesskey => "n", -title => "Alt-n"}, "next");
>
> Should not happen: href(-replay=>1, ...) should have the same value
> of 'a' parameter as the page it is in, so it should be 'log' not 'search'.
>
> Will investigate.
Now I know what is happening. git_header_html() modifies parameters
in $cgi, and href(-replay, ...) uses paramemeters values from $cgi,
not saved in variables (although it could).
So the correct solution would be to change the part which generates
search form in git_header_html() to _not_ modify $cgi->params().
Patch will follow...
P.S. I wonder if using Test::WWW::Mechanize (from CPAN) to test
gitweb's HTML output would be a good idea...
--
Jakub Narebski
Poland
ShadeHawk on #git
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
