On Mon, Sep 20, 2010 at 10:59 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > Giuseppe Bilotta wrote: >> On Mon, Sep 20, 2010 at 1:02 AM, Jakub Narebski <jnareb@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html