On Mon, 16 Feb 2009, Sebastien Cevey wrote: > Selon Jakub Narebski <jnareb@xxxxxxxxx>: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > > > * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits > > > - gitweb: Optional grouping of projects by category > > > - gitweb: Split git_project_list_body in two functions > > > - gitweb: Modularized git_get_project_description to be more generic > > > > > > Design discussion between Jakub and Sebastien seems to have stalled. > > > > But I am bit stalled at second patch in the series, which extract > > _printing_ the rows in separate function... while it should IMHO also > > refactor _filtering_ projects list, and not have "filtering as we > > print" current code uses... which would be night incompatibile with > > dividing projects list into pages. > > > > I think this patch series is definitely for after 1.6.2 > > Okay, I am sorry but I'm going to give up at this point. This patch has been in > the pipeline since July 27, 2008. I am sorry to hear about that. A bit of it is a bad timing (hitting feature freeze before release of next major version of git), some of it is my fault not reviewing patches fast enough. Some of it bad communication: me not writing review (and you not prodding), you not resending patches (and me not prodding.) > I understand the iterative review process to > ensure a certain code quality and acknowledge that these patches weren't > perfect (and probably still aren't), but it's a bit too much of extra rewrite to > support features that didn't exist and still don't exist yet AFAIK (page splitting of > projects page?). You are right, and I am sorry about that. That was a bit of overeager overengineering on my part. If we skip this unnecessary future-proofing the code, two things that are left to be corrected is mentioned in this thread changing order of parameters and better commit message for 1st patch, and IIRC removing unnecessary sorting in 3rd patch in series. > Feel free to take over and do the changes you have in mind, > it'd probably be faster than trying to guide me through it; I still believe > it'd be a welcome feature, and we've been waiting for it to be merged upstream for > quite a while to activate it on the XMMS2 gitweb. I have those patches in my clone of git, and I would tinker with them if you don't want to spend more time on them. > > I have to admit I'm not particularly fond of hacking Perl, but the effort to > get this rather simple and isolated feature merged don't make it very attractive. OTOH there were many features and improvements to git and gitweb that were send, and resend, and still aren't there (e.g. AJAX-y blame in gitweb, vcs-* microformat in gitweb, sparse checkout in git, refs/replace in git, etc.). > > It's a single 6300+ line Perl script we're talking about after all. gitk has 10000+ lines... in Tcl/Tk... git-svn has 5300+ lines, not much less... -- 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
