git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Tony Finch <dot@dotat.at>
Date
Jul 22, 2015, 10:05 UTC
Message-ID
<alpine.LSU.2.00.1507220957350.16350@hermes-1.csi.cam.ac.uk>
In-Reply-To
<55AE8ACF.6090508@gmail.com>
Jakub Narębski <jnareb@gmail.com> wrote:
>
Thanks for the review!
Show 8 quoted lines
> > * tf/gitweb-project-listing (2015-03-19) 5 commits
> >  - gitweb: make category headings into links when they are directories
> >  - gitweb: optionally set project category from its pathname
> >  - gitweb: add a link under the search box to clear a project filter
> >  - gitweb: if the PATH_INFO is incomplete, use it as a project_filter
> >
> >  Update gitweb to make it more pleasant to deal with a hierarchical
> >  forest of repositories.

By the way, you can see this patch series in action at https://git.csx.cam.ac.uk/x/ucs/

Show 5 quoted lines
> Second one, "gitweb: if the PATH_INFO is incomplete, use it as a
> project_filter" looks interesting and quite useful. Though it doesn't
> do much: it allows for handcrafted URL, and provides mechanism to
> create breadcrumbs. It doesn't use this feature in its output...
> Well, I think it doesn't: I cannot check it at this moment.
Hmm, I think this means I need a better commit message.

This patch fixes the ugly query-parameter URLs in the breadcrumbs that you get even in path-info mode. Have a look at the breadcrumbs on the following pages:

https://git.csx.cam.ac.uk/g/ucs/git/git.git (unpatched) https://git.csx.cam.ac.uk/x/ucs/git/git.git (patched)

If you click on the antepenultimate /git/ in the breadcumbs you get query parameters without the patch and path_info with the patch. With the patch the breadcrumbs match the URL.

> What is missing is a support for query parameters path, and not only
> path info.

Query parameter support is already present, in the form of project filters.

> Thought some thought is needed for generating (or not) breadcrumbs
> if path_info is turned off.
That already works in unpatched gitweb.
Show 6 quoted lines
> The third, "gitweb: add a link under the search box to clear a project
> filter" notices a problem... then solves it in strange way. IMVHO
> a better solution would be to add "List all projects" URL together
> with " / " (or other separator) conditionally, if $project_filter
> is set. Or have "List all projects" and add "List projects$limit"
> if $project_filter is set.
Yes, that is exactly what the patch does. I used a suffix "if" to align
the print statements and markup:
+           if $project_filter;
Compare and contrast the search box on these pages:

https://git.csx.cam.ac.uk/g/ucs/?a=project_list;pf=u/fanf2 https://git.csx.cam.ac.uk/x/ucs/u/fanf2/

Perhaps you would prefer the following?
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5549,10 +5549,14 @@ sub git_project_search_form {
              "</span>\n" .
              $cgi->submit(-name => 'btnS', -value => 'Search') .
              $cgi->end_form() . "\n" .
-             $cgi->a({-href => href(project => undef, searchtext => undef,
-                                    project_filter => $project_filter)},
-                     esc_html("List all projects$limit")) . "<br />\n";
-       print "</div>\n";
+             $cgi->a({-href => $my_uri}, esc_html("List all projects"));
+       if ($project_filter) {
+               print " / " .
+                   $cgi->a({-href => href(project => undef, action => "project_list",
+                                          project_filter => $project_filter)},
+                           esc_html("List projects$limit"));
+       }
+       print "<br />\n</div>\n";
 }

 # entry for given @keys needs filling if at least one of keys in list

> The last two, which form the crux of this patch series, looks like
> a good idea, though not without a few caveats. I am talking here
> only about conceptual level, not about how it is coded (which has
> few issues as well):
>
> - I think that non-bare repositories "repo/.git" should be
>   treated as one directory entry, i.e. gitweb should not create
>   a separate category for "repo/".  This is admittedly a corner
>   case, but useful for git-instaweb

Yes, that's a bug, thanks for spotting it!

> - 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.

I will send a new version of the series shortly.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Viking, North Utsire: Westerly 4 or 5, occasionally 6 at first, backing
southerly 3 or 4. Moderate becoming slight. Occasional rain in north. Good,
occasionally moderate.
Previous: Jakub NarębskiNext: Jakub Narębski
Message 5 of 9 in “What's cooking in git.git (Jul 2015, #01; Wed, 1)”
  1. Junio C HamanoJul 1, 2015
  2. Matthieu MoyJul 2, 2015
  3. Junio C HamanoJul 3, 2015
  4. Jakub NarębskiJul 21, 2015
  5. Tony FinchJul 22, 2015
  6. Jakub NarębskiJul 22, 2015
  7. Tony FinchJul 22, 2015
  8. Jakub NarębskiJul 22, 2015
  9. Tony FinchJul 22, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.