On Mon, Sep 20, 2010 at 1:02 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > When thinking about how display information about remotes and > remote-tracking branches in 'summary' view, we have to consider that > this view is meant to be what it says: a *summary*. That is why both > the 'heads' and the 'tags' section displays only 15 items. > > Without grouping remote heads the natural solution was to simply repeat > what we used for 'heads' subsection, namely limit displaying to 15 > remote-tracking branches in 'remotes' subsection of the 'summary' view. > > With grouping it is more complicated. We can limit number of remote > head *per remote*, we can limit number of remotes... but what makes > IMVHO least sense is limit number of remote heads *then* do grouping. This is something I absolutely agree with, BTW. It is the way it's implemented currently because it was the quickest way to ship a prototype out for discussion. > 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? > 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. >> If we go with option 3, it does make sense to get all remote names and >> all remote branches at once, and thus to make the git_get_remotes() >> call do all of the work. > > Not if subroutine is called git_get_remotes(), IMVHO. Perhaps > git_group_remotes()? That I can do. >> It's the only current use but I believe that, since it's factored out >> now already and since it may be used in other views too (think: >> grouping heads or tags by prefix) it might make sense to keep it this >> way. > > If it could be used for other blocks (like 'readme', or 'heads', > or 'tags') itself it would be even better. That's a possibility, although it would change the layout some (which is not necessarily a bad thing) > If remote doesn't have remote-tracking branches associated with it > (e.g. push-only remote, or remote predating separate remotes layout) > the value would be undef for given remote as key in hash. 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). -- 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