Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: >> If you then do a lookup for "foo/bar/baz/file2", it can use the exact >> same stack without looking for or reparsing the attribute files. If you >> then do a lookup for "foo/bar/bleep/file", it pops only the entry for >> "foo/bar/baz/.gitattributes", and pushes only the entry for >> "foo/bar/bleep/.gitattributes". > > I see. Thanks for the excellent explanation- I'll try implementing > this scheme. I somehow have a feeling that you did not read the conclusion in Peff's message correctly. The code only keeps data from one active path of per-directory .gitattributes files to the leaf of a working tree and releases unneeded data (IOW, it "pops" the attr_stack elements) when it goes on to look at the next path, so my understanding is that there is nothing to "try implementing" here. Unless attr.c::free_attr_elem() is leaky, that is. If that were the case, such a leak will accumulate and would make a difference. -- 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