Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)

["Jakub Narębski" <jnareb@gmail.com>]

W dniu 2015-07-22 o 15:19, Tony Finch pisze:
> Jakub Narębski <jnareb@gmail.com> wrote:
>>
>> A question about implementation: why emptying $path_info in
>> evaluate_path_info()?
> 
> That was for consistency with other parts of the subroutine which (mostly)
> remove items from the global $path_info variable when they are added to
> %input_params. But since $path_info isn't used after it has been parsed, I
> suppose it is redundant.

If it is for consistency, better leave it in my opinion.

>>>> - I think that people would want to be able to configure how
>>>>   many levels of directory hierarchy gets turned into categories.
>>>>   Perhaps only top level should be turned into category? Deep
>>>>   hierarchies means deep categories (usually with very few
>>>>   repositories) with current implementation.
>>>
>>> Good question. I was assuming flat-ish directory hierarchies, but that's
>>> clearly not very true, e.g. https://git.kernel.org/cgit/
>>>
>>> I think it would be right to make this a %feature since categories already
>>> nearly fit the %feature per-project override style.
>>
>> On the other hand $projects_list_group_categories is a global gitweb
>> configuration variable, and $projects_list_directory_is_category was
>> patterned after it.
> 
> Yes... Which do you prefer? :-)

Hmmm... does it makes sense to have per-repository override?  If yes,
then we need to use %features. If not... I am not sure, %features is
newer than global (or rather package) variables for gitweb configuration,
which must be left for legacy config support (and few are needed before
%features are parsed).

>> A few thoughts about implementation:
> 
> Helpful, thanks!
> 
>> - can we turn category header into link even if the category didn't
>>   came from $projects_list_directory_is_category?
> 
> That would mean changing the project filter to match categories as well as
> paths. I don't know if this is the right thing to do; perhaps it is,
> because the current behaviour of my category headings is a bit surprising.
> 
> At the moment, clicking on the "git" category heading on the page linked
> below takes you to a page that does not list all the repos that were under
> the category heading on the main page.
> 
> https://git.csx.cam.ac.uk/x/ucs/

I thought gitweb had a way to list all projects belonging to given category,
but I see that it doesn't.  So you need to find out if 'category' came from
category or from pathname, to decide whether to link it using 'projects_list'
action and 'project_filter' parameter (or their PATH_INFO version), or not.

This can be done either by checking that category name is directory (though
we could have false positives here), or when adding categories denote where
it came from (e.g. with additional field).  I think the second is better,
if we are to hyperlink category-from-pathname headings.

There is interesting corner case: what if some projects use category, and
some have the same category from pathname?  Clicking on category if 
hyper-linked would show only a subset of projects inside category. (I think
this is the oddity you noticed.)

>> - even if $projects_list_directory_is_category is true, the category
>>   could came from 'category' file, or otherwise manually set category,
>>   though I wonder how we can easily detect this...
> 
> Yes - I use this to list my personal/experimental repos alongside
> the production repos.
> 
> I'm not sure why gitweb would need to detect this or what it would do in
> response. At the moment it "just works", apart from the oddity with
> categories vs project filters i described above.

What if there is synthetic category that has no representative in the
path hierarchy?  Then "project_filter" link would lead to strange empty
list of projects...

For example http://git.zx2c4.com/ (cgit) uses "Mirrors" category...

We could either abuse "project_filter" for categories, or add a new
query parameter "project_category" or "cat" in short. In either case
it would not have PATH_INFO URL unless category came from directory.

Food for thought
-- 
Jakub Narębski