git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
Date: Thu, 9 Feb 2012 23:36:48 +0100	[thread overview]
Message-ID: <201202092336.48772.jnareb@gmail.com> (raw)
In-Reply-To: <7vhayzvf38.fsf@alter.siamese.dyndns.org>

On Thu, 9 Feb 2012, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > This could have been squashed with the next commit, but this way it is
> > pure refactoring that shouldn't change gitweb behavior.
> 
> It is not obvious why this shouldn't change gitweb behaviour from the
> patch text.
> 
> The old code says "Unconditionally call git_get_last_activity(), and if we
> found nothing, do not do anything extra for this project". The new code
> says "we do that but only if the project does not know its 'age' yet".

Well, till next patch in this series gitweb always filled some parts of
project info by processing $projects_list i.e. reading a file or scanning
a directory.  Then fill_project_list_info was called to fill the rest
of projects data.

Which parts were filled in first step depends on whether $projects_list
is a file with list of projects or a directory to scan, but 'age' was 
_never_ filled.

But I agree that it is not obvious.


I think that better solution would be to either squash 1/5 and 2/5, or
make 1/5 only about introduction of project_info_needs_filling(), without
@fill_only but with the 'age' check change.

> The lack of any real use of @fill_only in this patch also makes it hard to
> judge if the new API gives a useful semantics.  I would, without looking
> at the real usage in 2/5 patch, naïvely expect that such a lazy filling
> scheme would say "I am going to use A, B and C; I want to know if any of
> them is missing, because I need values for all of them and I am going to
> call a helper function to fill them if any of them is missing. Having A
> and B is not enough for the purpose of this query, because I still need to
> know C and I would call the helper function that computes all of them in
> such a case. Even though it might be wasteful to recompute A and B,
> computing all three at once is the only helper function available to me".
> 
> So for a person who does not have access to the real usage of the new API,
> being able to give only a single $key *appears* make no sense at all, and
> also the meaning of the @fill_only parameter is unclear, especially the
> part that checks if that single $key appears in @fill_only.

fill_project_list_info() is, at least after a fix with 'age', about filling
information that is not already present.  If @fill_only is nonempty, it
fills only selected information, again only if it is not already present.
@fill_only empty means no restrictions... which probably is not very obvious,
but is documented.

project_info_needs_filling() returns true if $key is not filled and is
interesting.
 
> > Adding project_info_needs_filling() subroutine could have been split
> > into separate commit, but it would be subroutine without use...
> >
> >  gitweb/gitweb.perl |   41 +++++++++++++++++++++++++++++++----------
> >  1 files changed, 31 insertions(+), 10 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index 913a463..b7a3752 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -5185,35 +5185,56 @@ sub git_project_search_form {
> >  	print "</div>\n";
> >  }
> >  
> > +# entry for given $key doesn't need filling if either $key already exists
> > +# in $project_info hash, or we are interested only in subset of keys
> > +# and given key is not among @fill_only.
> > +sub project_info_needs_filling {
> > +	my ($project_info, $key, @fill_only) = @_;

So in new version @fill_only will be removed...

> > +
> > +	if (!@fill_only ||            # we are interested in everything
> > +	    grep { $key eq $_ } @fill_only) { # or key is in @fill_only
> > +		# check if key is already filled
> > +		return !exists $project_info->{$key};

...and this will be the only line of project_info_needs_filling() wrapper.

> > +	}
> > +	# uninteresting key, outside @fill_only
> > +	return 0;
> > +}
> > +
> >  # fills project list info (age, description, owner, category, forks)
> >  # for each project in the list, removing invalid projects from
> > -# returned list
> > +# returned list, or fill only specified info (removing invalid projects
> > +# only when filling 'age').
> > +#
> >  # NOTE: modifies $projlist, but does not remove entries from it
> >  sub fill_project_list_info {
> > -	my $projlist = shift;
> > +	my ($projlist, @fill_only) = @_;

Here also @fill_only would be not present.

> >  	my @projects;
> >  
> >  	my $show_ctags = gitweb_check_feature('ctags');
> >   PROJECT:
> >  	foreach my $pr (@$projlist) {
> > -		my (@activity) = git_get_last_activity($pr->{'path'});
> > -		unless (@activity) {
> > -			next PROJECT;
> > +		if (project_info_needs_filling($pr, 'age', @fill_only)) {

This change makes 'age' not special.

[...]

-- 
Jakub Narebski
Poland

  reply	other threads:[~2012-02-09 22:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-04 12:47 [PATCH 0/5] gitweb: Faster and imrpoved project search Jakub Narebski
2012-02-04 12:47 ` [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info Jakub Narebski
2012-02-09 22:04   ` Junio C Hamano
2012-02-09 22:36     ` Jakub Narebski [this message]
2012-02-09 23:18       ` Junio C Hamano
2012-02-09 23:52         ` Jakub Narebski
2012-02-09 23:56           ` Junio C Hamano
2012-02-10 13:56             ` Jakub Narebski
2012-02-10 17:43               ` Junio C Hamano
2012-02-10 18:17                 ` Jakub Narebski
2012-02-10 19:49                   ` Junio C Hamano
2012-02-10 21:30                     ` Jakub Narebski
2012-02-10 21:44                       ` Junio C Hamano
2012-02-10 22:07                         ` Jakub Narebski
2012-02-04 12:47 ` [PATCH 2/5] gitweb: Faster project search Jakub Narebski
2012-02-04 12:47 ` [PATCH 3/5] gitweb: Highlight matched part of project name when searching projects Jakub Narebski
2012-02-04 12:47 ` [PATCH 4/5] gitweb: Highlight matched part of project description " Jakub Narebski
2012-02-04 12:47 ` [PATCH/RFC 5/5] gitweb: Highlight matched part of shortened project description Jakub Narebski
2012-02-04 18:56   ` [PATCH/RFCv2 " Jakub Narebski
2012-02-04 20:07 ` [PATCH 0/5] gitweb: Faster and imrpoved project search Felipe Contreras
2012-02-04 20:59   ` Jakub Narebski

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=201202092336.48772.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).