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. > The last three patches are more of the RFC side, in particular the last > one. The idea is to group remote heads 'by remote' instead of just > listing them serially. So I first introduce code and styling to have > 'blocks of stuff' in gitweb, and then use this concept to group together > remote heads belonging to the same remote. This is a good idea in itself; I'd take a look at implementation and styling when examining individual patches. > 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. 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). > 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. -- Jakub Narebski Poland -- 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