Re: [PATCH v2 03/11] gitweb: separate heads and remotes list in summary view

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2008/11/14 Jakub Narebski <jnareb@xxxxxxxxx>:> Dnia czwartek 13. listopada 2008 23:49, Giuseppe Bilotta napisał:>> Very nice patch. Now that I have read it, I don't think it should be> squashed with previous patch (well, again that is only a suggestion).
See reply in previous patch. Sometimes it's hard to tell what's thebest patch-splitting strategy ...
> Barring one issue (see below) its conciseness shows that gitweb has> quite good internal API.
Most definitely. I find that working on gitweb is almost pleasurable ;-)[I mean, it's still Perl, which is not Tcl but not Ruby either 8-P]
>>       my @forklist;>>       my ($check_forks) = gitweb_check_feature('forks');>>>> @@ -4535,6 +4537,13 @@ sub git_summary {>>                              $cgi->a({-href => href(action=>"heads")}, "..."));>>       }>>>> +     if (@remotelist) {>> +             git_print_header_div('remotes');>> +             git_heads_body(\@remotelist, $head, 0, 15,>> +                            $#remotelist <= 15 ? undef :>> +                            $cgi->a({-href => href(action=>"heads")}, "..."));>> +     }>> +>> The only problem is that link leads to list of _all_ heads (best case),> or list to local branches (worst case, but I don't think gitweb does> it), instead of only list of remotes refs (remote-tracking branches),> as one would think.  Perhaps we could use 'h' (hash), or 'opt (extra> options) parameter for this action, or just add 'remotes' action?
Adding a 'remotes' section (and corresponding action, too) is what isdone by subsequent patches. It's quite obvious, I think, that thepatch sequence follows _very_ closely the order in which Iimplemented/tested features. It might make more sense to move some ofthem earlier, but then such earlier patches would only make sensebecause of the ones that follow ... this is why I decided to keep thesequence as is.
>> 1.5.6.5>> P.S. Not uptodate (git version 1.6.0.4)? Just kidding...
Yeah, I know, given that I work with 'next' gitweb, I could as welljust upgrade the system git to the same version 8-P
Instead, I'm just relying on stock Debian stuff, which obviously,being in freeze now, is not updating unstable either 8-P

-- Giuseppe "Oblomov" Bilotta˙ôčş{.nÇ+?ˇ?Ž?­?+%?Ë˙ąéÝśĽ?w˙ş{.nÇ+?ˇ ?ßâ?Ř^n?rĄöŚzË?ëh?¨č­Ú&ŁűŕzżäzšŢ?ú+?Ę+zfŁ˘ˇh??§~?­?Űi˙˙ď?ę˙?ęçz_čŽćj:+v?¨ţ)ߣřm


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux