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

Re: [PATCHv6 10/10] gitweb: group remote heads by remote

From
Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date
Nov 8, 2010, 08:28 UTC
Message-ID
<AANLkTimxspcGLnv+F6uKAnFAhUO++iB10b5GxnLVg_v3@mail.gmail.com>
In-Reply-To
<201011041141.58334.jnareb@gmail.com>
On Thu, Nov 4, 2010 at 11:41 AM, Jakub Narebski <jnareb@gmail.com> wrote:
Show 9 quoted lines
> On Wed, 3 Nov 2010, Giuseppe Bilotta wrote:
>>
>> I think that in most cases there won't be any need for limiting.
>> Public cases of lots of remotes with lots of branches are, I suspect,
>> rare.
>
> It's not about _public_ cases; I think that it is in very rare cases
> that public repository would want to display remotes and remote-tracking
> branches.
That's a good point.
Show 7 quoted lines
> I think remote_heads feature is more important for _local_ use, for
> example browsing one own repository using git-instaweb.  In such cases
> number of remotes and of remote-tracking branches might be large (I have
> 11 remotes, not all active, and 58 remote-tracking branches).
>
> BTW. would next version of this series include patch to git-instaweb
> enabling 'remote_heads' feature for it (gitweb_conf function)?
I will look into that.
Show 46 quoted lines
>> with all the remotes/<remotename> pathspecs as a single array
>> argument. This _does_ mean that when the total number of remote heads
>> is greater than the limit some remotes will not display complete
>> information in summary view. The real issue here is, I think, that
>> there is no trivial way to tell which remotes have incomplete
>> information and which don't, meaning that in the subsequent
>> git_remote_block calls we'll have no way to provide visual feedback
>> (the ellipsis) when some heads are missing.
>
> Errr... shouldn't we leave limiting number of heads to fill_remote_heads,
> which can do limiting per remote (with each remote having up to $limit
> remote-tracking branches / remote heads), instead of having
> git_get_heads_list do it?
>
> Something like this:
>
> +sub fill_remote_heads {
> +       my ($remotes, $limit) = @_;
> +
> +       my @heads = map { "remotes/$_" } keys %$remotes;
> +       my @remoteheads = git_get_heads_list(undef, @heads);
> +       foreach my $remote (keys %$remotes) {
> +               $remotes->{$remote}{'heads'} =
> +                       [ grep { $_->{'name'} =~ s!^$remote/!! } @remoteheads ];
> +               $remotes->{$remote}{'heads'} =
> +                       [ @{$remotes->{$remote}{'heads'}}[0..$limit-1] ]
> +                       if (@{$remotes->{$remote}{'heads'}} > $limit);
> +       }
> +}
>
> Though perhaps it will be more clear with if as statement, not as modifier:
>
> +sub fill_remote_heads {
> +       my ($remotes, $limit) = @_;
> +
> +       my @heads = map { "remotes/$_" } keys %$remotes;
> +       my @remoteheads = git_get_heads_list(undef, @heads);
> +       foreach my $remote (keys %$remotes) {
> +               $remotes->{$remote}{'heads'} =
> +                       [ grep { $_->{'name'} =~ s!^$remote/!! } @remoteheads ];
> +               if (@{$remotes->{$remote}{'heads'}} > $limit) {
> +                       $remotes->{$remote}{'heads'} =
> +                               [ @{$remotes->{$remote}{'heads'}}[0..$limit-1] ]
> +               }
> +       }
> +}

Either solution is fine, but it would require grabbing all the remote heads. The real issue here is, I think understanding what is the purpose of limiting in gitweb. Is it to reduce runtime? is it to reduce clutter on the screen? In the first case, the limiting should be done as early as possible (i.e. during the git call that retrieves the data); in the latter case, is it _really_ needed at all?

-- 
Giuseppe "Oblomov" Bilotta
Previous: Jakub NarebskiNext: Jakub Narebski
Message 28 of 33 in “[PATCHv6 00/10] gitweb: remote_heads feature”
  1. Giuseppe BilottaOct 24, 2010
  2. 01/10 gitweb: introduce remote_heads featureGiuseppe Bilotta, Oct 24, 2010
  3. 02/10 gitweb: git_get_heads_list accepts an optional list of refs.Giuseppe Bilotta, Oct 24, 2010
  4. Jakub NarebskiOct 25, 2010
  5. Giuseppe BilottaOct 26, 2010
  6. 03/10 gitweb: separate heads and remotes listsGiuseppe Bilotta, Oct 24, 2010
  7. Jakub NarebskiOct 25, 2010
  8. Giuseppe BilottaOct 25, 2010
  9. 04/10 gitweb: nagivation menu for tags, heads and remotesGiuseppe Bilotta, Oct 24, 2010
  10. 05/10 gitweb: use fullname as hash_base in heads linkGiuseppe Bilotta, Oct 24, 2010
  11. Jakub NarebskiOct 25, 2010
  12. Giuseppe BilottaOct 25, 2010
  13. 06/10 gitweb: allow action specialization in page headerGiuseppe Bilotta, Oct 24, 2010
  14. 07/10 gitweb: remotes view for a single remoteGiuseppe Bilotta, Oct 24, 2010
  15. Jakub NarebskiOct 25, 2010
  16. Giuseppe BilottaOct 25, 2010
  17. 08/10 gitweb: refactor repository URL printingGiuseppe Bilotta, Oct 24, 2010
  18. 09/10 gitweb: provide a routine to display (sub)sectionsGiuseppe Bilotta, Oct 24, 2010
  19. Jakub NarebskiOct 25, 2010
  20. Giuseppe BilottaOct 25, 2010
  21. 10/10 gitweb: group remote heads by remoteGiuseppe Bilotta, Oct 24, 2010
  22. Jakub NarebskiOct 27, 2010
  23. Jakub NarebskiOct 27, 2010
  24. Giuseppe BilottaNov 2, 2010
  25. Jakub NarebskiNov 2, 2010
  26. Giuseppe BilottaNov 3, 2010
  27. Jakub NarebskiNov 4, 2010
  28. Giuseppe BilottaNov 8, 2010
  29. Jakub NarebskiNov 8, 2010
  30. Giuseppe BilottaNov 8, 2010
  31. Jakub NarebskiNov 8, 2010
  32. Jakub NarebskiOct 27, 2010
  33. Jakub NarebskiOct 25, 2010

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.