Stefan Beller <sbel...@google.com> writes: >> static void collect_some_attrs(const char *path, int pathlen, >> - struct git_attr_check *check) >> + struct git_attr_check *check, int collect_all) > > I think it may be better to have a collect_all_attrs instead of a flag here, > as more than half the executed code differs (the parts conditioned on > collect_all are rather large in the function)
It is understandable if it appears to anybody who does not know the future that way ;-) The plan is to remove that "if (!collect_all)" optimization block. Once the attr_stack and check_all_attr becomes per git_attr_check instance, there is no reason to keep record of all attribute definitions read from the .gitattribute files. The entries that are known not to matter (i.e. not listed in git_attr_check) can be discarded when they are read before it hits attr_stack. The "optimization" in that block is to optimize one special case: an attribute may be defined in the git_attr_hash[] dictionary, and the ones that appeared in various .gitattribute files are marked with a bit (an attribute may be in that dictionary only because the caller who asks about the attribute filled it in check->check[] array, and may not appear in the .gitattribute files prepare_attr_stack() read). If the check->check[] wants to know about an attribute that does not appear in any of the .gitattribute files, we can answer "that attribute is not set to anything" without actually executing any matches with path patterns. The "an attr_stack that is per git_attr_check only has to contain what matters and can discard irrelevant records" is a natural extension of the current optimization. Instead of the current "when 0 rules refer to attribute, do not do any of the 47 path matches defined in the attribute system, but even if one rule refers to it, do all 47 path matches to check", we would do "among 47 path patterns, only attempt to match patterns that affect the attributes that we are checking (which could be 0 rules). -- 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
