git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Sebastien Cevey <seb@cine7.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Feb 2009, #04; Sun, 15)
Date: Mon, 16 Feb 2009 17:44:45 +0100	[thread overview]
Message-ID: <200902161744.46450.jnareb@gmail.com> (raw)
In-Reply-To: <1234798042.499985da2915e@mail.nimag.net>

On Mon, 16 Feb 2009, Sebastien Cevey wrote:
> Selon Jakub Narebski <jnareb@gmail.com>:
> > Junio C Hamano <gitster@pobox.com> 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

      reply	other threads:[~2009-02-16 16:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-15 10:40 What's cooking in git.git (Feb 2009, #04; Sun, 15) Junio C Hamano
2009-02-15 11:12 ` Jakub Narebski
2009-02-16 15:27   ` Sebastien Cevey
2009-02-16 16:44     ` Jakub Narebski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200902161744.46450.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=seb@cine7.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).