Karthik Nayak <karthik.188@xxxxxxxxx> 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.
--
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