Re: [PATCH] gitweb: fix link to parent diff with pathinfo
- From
Jakub Narębski <jnareb@gmail.com>
- Date
- May 25, 2016, 20:33 UTC
- Message-ID
- <CANQwDwdKaVDGDxZZma25WcV+ea90YtFhDedLwv2KNZt6jhKVAQ@mail.gmail.com>
- In-Reply-To
- <xmqq37p75nif.fsf@gitster.mtv.corp.google.com>
On Tue, May 24, 2016 at 8:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 5 quoted lines
> Richard Braun <rbraun@sceen.net> writes: > >> Gitweb, when used with PATH_INFO, shows a link to parent diff >> like http://somedomain/somerepo.git/commitdiff/somehash?hp=parenthash. >> That link reports "400 - Invalid hash parameter".
Richard, at which view is this bad link present? Err... never mind, I see that gitweb uses link to 'commitdiff' view with 'hash_parent' parameter set only ..in two places (well, perhaps there are some which get hash_parent from -replay, but I doubt it): the "commit" view (link to each parent commit) and in "commitdiff" view for octopus merges (e.g. "pu" in git.git).
The problem is not with ?hp=parenthash, but with /somehash part, which somehow got invalid (from the error message). I have checked using http://repo.or.cz/git.git, and while it has the bug (i.e. uses '?hp=...' instead of path_info), there is no "400 - Invalid has parameter" error.
>> As I understand it, it should instead directly point to the parent diff, >> i.e. turn it into http://somedomain/somerepo.git/commitdiff/parenthash,
Actually, the correct path_info based URI would be
http://somedomain/somerepo.git/commitdiff/parenthash..somehash
Just like href() does with hash_parent_base and hash_base for blobdiff. Urgh... href() is a bit of mess, now I see it when I am not current.
>> and delete 'hash_parent' element from the %params hash once we used it, >> otherwise the '?hp=parenthash' string is appended.
That's correct: the unstated rule of href is that if it went into path_info, it is deleted (not everything can be expressed with path_info), the rest goes into query parameters. So without deleting the element, it would be duplicated.
Note that using query parameter when we can use path_info is a minor error; URL should work anyway (and I don't see why it doesn't - somewhat the 'hash' parameter got incorrect...).
Show 5 quoted lines
>> >> Signed-off-by: Richard Braun <rbraun@sceen.net> >> --- > > Pinging...
I'm sorry, I didn't notice it was meant for me. Simple "Jakub,..." would be enough.
On Tue, May 24, 2016 at 8:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> Richard Braun <rbraun@sceen.net> writes: > >> On Tue, May 24, 2016 at 11:17:28AM -0700, Junio C Hamano wrote: >>> Pinging... >> >> Hum, see [1]. >> >> Tell me if I need to resend. > > Sorry, check the "To:" field of the message you are responding to. > The ping was not meant to (and was not addressed to) you. It asked > for comments from an area expert.
Only this made me realize that you are expecting *my* response.
Show 18 quoted lines
>> gitweb/gitweb.perl | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index 05d7910..f7f7936 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -1423,7 +1423,12 @@ sub href {
>> delete $params{'hash'};
>> delete $params{'hash_base'};
>> } elsif (defined $params{'hash'}) {
>> - $href .= esc_path_info($params{'hash'});
>> + if (defined $params{'hash_parent'}) {
>> + $href .= esc_path_info($params{'hash_parent'});
>> + delete $params{'hash_parent'};
>> + } else {
>> + $href .= esc_path_info($params{'hash'});
>> + }This should read _something_ like this
+ if (defined $params{'hash_parent'}) {
+ $href .=
esc_path_info($params{'hash_parent'}) . '..';
+ delete $params{'hash_parent'};
+ }
+ $href .= esc_path_info($params{'hash'});
+ delete $params{'hash'};Otherwise you would get correct link in your situation with bad 'hash' parameter, but not the view that was requested; it would not be diff between current and given parent, but commitdiff for parent (to grandparent(s)).
Richard, thanks for finding a problematic thing, but you need to search more for a true fix.
Regards
-- Jakub Narebski