On Wed, Dec 18, 2024 at 06:53:31AM -0800, Junio C Hamano wrote: > > 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. Yeah, I agree it's somewhat orthogonal. Your patch made me think about it because it is advertising the config variant more widely. Somebody doing: git --attr-source=foo diff ... is probably OK, but: git --attr-source=foo pack-objects ... is less so. Using attr.tree instead means you're going to do the latter whether you intended to or not. -Peff
