On Wed, Sep 2, 2015 at 9:45 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Karthik Nayak <karthik....@gmail.com> writes:
>
>>>> + if (filter->kind == FILTER_REFS_BRANCHES)
>>>> + ret = for_each_fullref_in("refs/heads/", ref_filter_handler,
>>>> &ref_cbdata, broken);
>>>> + else if (filter->kind == FILTER_REFS_REMOTES)
>>>> + ret = for_each_fullref_in("refs/remotes/", ref_filter_handler,
>>>> &ref_cbdata, broken);
>>>> + else if (filter->kind == FILTER_REFS_TAGS)
>>>> + ret = for_each_fullref_in("refs/tags/", ref_filter_handler,
>>>> &ref_cbdata, broken);
>>>> + else if (filter->kind & FILTER_REFS_ALL)
>>>> + ret = for_each_fullref_in("", ref_filter_handler, &ref_cbdata,
>>>> broken);
>>>
>>> This if/else if/else if/ cascade and ...
>>
>> Did you notice the "==" for others and "&" for the ALL?
>
> I didn't. Thanks for pointing it out.
>
> So the point of the earlier part of the cascade is to optimize for
> common cases? If that is the case, it probably deserves some
> commenting. I also suspect that a table-based control might be
> easier to maintain, but that kind of change might fall into the
> category of premature optimization.
Yes, thats the point.
Will add a comment, thanks :)
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
