Jeff King <peff@xxxxxxxx> writes: >> > I recall that the performance of attr.tree is not great for _some_ >> > commands (like pack-objects). So it's perhaps reasonable to use for >> > single commands like "git diff" but not to set in your on-disk config. >> > It's possible we'd want to warn people about that before advertising it >> > more widely? I dunno. >> >> Or we disable the unusably-inefficient feature before doing so. >> Would attr.tree be much less efficient than GIT_ATTR_SOURCE? > > Whether it's unusably inefficient depends on what you throw at it. IIRC, > the performance difference for pack-objects on git.git was fairly > negligible. The problem in linux.git is that besides being big, it has a > deep(er) directory structure. So collecting all of the attributes for a > file like drivers/gpu/drm/foo/bar.h needs to open all of those > intermediate trees. > > So I'd be inclined to leave it in place, in case somebody is actually > happily using it. > > GIT_ATTR_SOURCE suffers all of the same problems; it's just that you'd > presumably only use it with a few select commands (as far as I know, > pack-objects is the worst case because it's looking up one attribute on > every single blob in all of history). Ah, OK. So your "caution" was about the underlying mechanism to allow attributes corrected from the specified tree, and not specifically about using "attr.tree" to specify that tree? That was what got me confused. If that is the case, I do not think the documentation patch that started this exchange that adds attr.tree to where GIT_ATTR_SOURCE and --attr-source are already mentioned makes anything worse. Thanks.
