Junio C Hamano wrote:
> Jakub Narebski <jnareb@xxxxxxxxx> writes:
>
>>> Exactly. Why do you need @fill_only at all? If you are interested in
>>> ctags and you want to make sure ctags is available, the question you want
>>> to ask the helper function is "Does the project structure already have
>>> ctags field?". Why does the helper function needs to know anything else?
>>
>> It is to support incremental filling of project info. The code is to
>> go like this:
>>
>> create
>> filter
>> fill part
>> filter
>> fill rest
>>
>> We need @fill_only for the "fill part".
>
> Again, why?
So fill_project_list_info() knows what needs to be filled (notice: not
"what to fill"), as filter might need different fields in project info
to do its work.
> > As filling project info is
> > potentially expensive (especially the 'age' field),
>
> So you wouldn't say "I am interested in 'age' field" but show interest in,
> and fill, cheaper fields in the earlier "fill" calls, and then...
It is not about cheaper, it is about required by filter. It happens that
it is cheaper.
> > doing it on narrowed
> > (filtered) list of project is a performance win.
>
> ... you drop uninteresting projects by using the partially filled
> information, and show interest in more expensive 'age' in the later round
> for surviving projects.
>
> It still does not explain why you need @fill_only.
So I can use single subroutine fill_project_list_info() to fill what is
required, and to fill the rest of info.
create
filter
fill part('path', 'descr')
filter('path', 'descr')
fill rest
or
create
filter
fill part('ctags')
filter('ctags')
fill rest
Am I clear?
--
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