2010/9/16 Jakub Narebski <jnareb@xxxxxxxxx>: > On Thu, 16 Sep 2010, Giuseppe Bilotta wrote: > >> This is a rehash of an old patchset of mine that got stalled waiting for >> other independent patches to go in first, and then for me to get the >> time to work on it again. >> >> The first 4 patches are IMO ready for inclusing in gitweb, and their >> purpose is to introduce a new view (and a new summary block) that >> display all the remote heads (assuming the feature is enabled). >> Somebody suggested via email that this could even the basis for some >> kind of 'social graph' for gitweb repositories, in a way similar to what >> is found on sites like github or gitorious, but for me the feature in >> itself can already be useful. > > We might want to make git-instaweb enable this feature (and probably > other disabled-by-default features). Otherwise some of information > about git repository you examine is hidden. So I agree that this > feature is useful by itself. I'll add a patch to that effect in the next iteration. >> The final result is rather curious and you can see it in action at >> <http://git.oblomov.eu/rbot/remotes>, although it would be nice to find >> a way to layout the blocks in a smarter way. > > Thanks for providing demo site. > > Note that clicking on header for remote block, which should lead to > displaying of only single remote displays all remotes, see e.g. > http://git.oblomov.eu/rbot/remotes/a3li. Moreover when I tried to > handcraft URL i.e. http://git.oblomov.eu/rbot/remote/a3li (with > 'remote' rather than 'remotes' action) I get an empty list of heads. The /remote/<thing> is just the standard behavior of git when any random string is passed as PATH_INFO (try http://git.oblomov.eu/rbot/whatever), so I cannot fix that unless I map remote to remotes. The remotes/<headname> is a TODO (This led me to think: do we want heads/<headname> to point to the shortlog of that head? It currently does nothing) > About layout of 'remotes' view: to have remotes information aligned > we would have to either put everything in one single table (with remotes > headers being "colspan"), or style them with minimum width (which could > be good idea anyway). I don't like the 'one single table' approach because, in contrast to the current approach it doesn't allow for automatic block rearrangement based on the window width. The minimum width helps align the blocks vertically, but it doesn't align the contents of the tables in it, so it's not really that big an improvement (actually, I find it even funnier that way because of the illusion of alignment provided by the blocks). >> What I really don't like (at the moment) is the way things come out >> in summary view instead. > > What you don't like about it? Should it be smarter and display only > list of remotes, perhaps even limited to 15 elements, if there are many > remote-tracking branches? Or is it something else? > >> The issue there is that we only gather 16 remote heads, so some remotes >> might have no branches displayed, but it becomes difficult to detect and >> indicate when remotes have incomplete information being displayed. A >> possible solution would be to call show-ref N times (N being the number >> of remotes) with a limit of 16/N heads, but that can be a lot of calls. >> So I'm open to suggestions on how to improve this part (maybe just show >> a flat view in the remotes section of summary view?) > > Ah, I see... > > Alternatively we could use smart limiting on the gitweb side. That was an option I was considering. I thought the limiting to 16 refs and tags in summary view was for performance reasons, so I thought that grabbing all remote heads would kind of kill the remote view, but for sure it's more efficient than doing a ref retrieval for each remote. OTOH, once we get all the refs, why would we only display some of 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