Re: [PATCHv4] gitweb: parse project/action/hash_base:filename PATH_INFO

["Giuseppe Bilotta" <giuseppe.bilotta@gmail.com>]

>> >> @@ -534,8 +575,9 @@ sub evaluate_path_info {
>> >>               $file_name ||= validate_pathname($pathname);
>> >>       } elsif (defined $refname) {
>> >>               # we got "project.git/branch"
>> >> -             $action ||= "shortlog";
>> >> -             $hash   ||= validate_refname($refname);
>> >> +             $action    ||= "shortlog";
>> >> +             $hash      ||= validate_refname($refname);
>> >> +             $hash_base ||= validate_refname($refname);
>> >>       }
>> >>  }
>> >>  evaluate_path_info();
>> >
>> > What is this good for?
>>
>> The purpose of what? setting both $hash and $hash_base was something
>> that I found was needed in some extreme cases, as discussed with
>> Jakub. Proposals for recommended cleaner but equally fast way to
>> handle it. If you're referring to the whitespace, I was just lining up
>> the entries. Should I do it in a separate patch?
>
> I refer to the setting of $hash_base (I'm not huge fan of the whitespace
> aligning, but I don't really care). What extreme cases are these?
> I think you should describe that in the code since it's not really
> obvious. Maybe I could find it in older threads but I should understand
> the code just from reading it. :-)

In preparing the new patchset, I've put a big comment block explaining
why we need to set both $hash and $hash_base in this code-path:

# we got "project.git/[action/]branch". in this case
# we set both $hash and $hash_base because different actions
# need one or the other to be set to behave correctly.
#
# For example, if $hash_base is not set then the blob and
# history links on the page project.git/tree/somebranch will
# assume a $hash_base of HEAD instead of the correct
# somebranch.
# Conversely, not setting $hash will make URLs such as
# project.git/shortlog/somebranch display the wrong page.
#
# Since it also turns out that the unused one is properly
# overwritten as needed, setting both is quite safe.


-- 
Giuseppe "Oblomov" Bilotta