Re: [PATCH 7/7] gitweb: group remote heads

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

On Mon, Sep 20, 2010 at 10:59 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>> On Mon, Sep 20, 2010 at 1:02 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> > The solution (1) i.e. limiting number of remote heads per remote, with
>> > or without limiting number of remotes behaves, as you wrote, most
>> > similarly to other components of 'summary' view.  On the other hand
>> > with large number of remotes, and large number of remote heads in those
>> > remotes it might be too large for a *summary* view.
>>
>> So you maintain that limiting the amount of data in summary view
>> should be primary wrt to limiting the amount of time?
>
> Well, what really affect gitweb performance is calling git commands, both
> because of fork overhead, and because it means disk access (and gitweb
> performance from what I have heard is affected mainly by IO, and not CPU).
> With grouping (displaying remotes) the difference between displaying
> remote-tracking branches (or information from them) and not displaying
> them is an argument to git-for-each-ref.  So I don't think it would
> affect performance much.

Getting the list of remote branches is, I would say, the most
IO-intensive operation. I'm not sure how much I/O it would do though,
even with a large number of remotes and heads. So maybe always gather
all the information is the way to go.

>> > The solution (3) i.e. displaying only list of remotes (perhaps limited
>> > to 15 remotes) is simple and fast to render.  On the other hand it offers
>> > least information and might be too little in the case of single remote.
>>
>> If time spent processing is not an issue, we can retrieve the number
>> of heads for each remote and display that, for example. Or even play
>> with some more dynamic stuff like making each group collapsible,
>> starting with it collapsed and then display the content when the user
>> hovers it with the mouse, for example.
>
> The dynamic stuff is IMHO a good idea... provided we can either do it
> without JavaScript, or we can ensure that browser supports JavaScript
> (see current hack used for turning 'blame' into 'blame_incremental'
> view in gitweb).

What I had in mind was something that is very easy to implement with CSS only.

> Yet another solution would be to display only abbreviated list of remotes
> if its more of them than some threshold, and list remotes with abbreviated
> list of remote-tracking branches if there are only a few remotes.

So something like this:

(1) if there are more than N remotes, only show N remote _names_ (no heads)
(2) if there are no more than N remotes, show all remote names, each
with no more than M heads

(with N and M to be decided, e.g. the usual 16)

>> Yes, this is something I have to take into consideration. Skip
>> displaying them is probably the best idea (unless we have other ways
>> to gather information about them).
>
> Right.

For this, it would be nice to have `git remote show`, but even if I
sent a patch to this effect gitweb should probably be left able to
cope with older git versions not supporting it ...

> P.S. It is not necessary for this series, but I think we should think
> about "single remote" view... also because your code currently links
> to such views, which do not exist yet (remotes/<remote> in path_info:
> how it would be represented in CGI query format?).

Maybe pass the remote name as head parameter?

-- 
Giuseppe "Oblomov" Bilotta