Re: [PATCHv4] gitweb: parse project/action/hash_base:filename PATH_INFO
- From
Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
- Date
- Oct 2, 2008, 21:05 UTC
- Message-ID
- <cb7bb73a0810021405j68b0a164i9469e64afc543ebf@mail.gmail.com>
- In-Reply-To
- <20081002205603.GW10360@machine.or.cz>
Show 26 quoted lines
>> >> @@ -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