Junio C Hamano wrote: > 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. My bad- I thought the current implementation doesn't release the unneeded data. So, does the entire 7 KB of leaked data come from one active path? -- Ram -- 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