Re: leaky cherry-pick

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 11, 2012, 08:16 UTC
Message-ID: <7vipki7ix9.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0kDnxjtQ+ihH_dif_7yivHLd=pibao4KPs_PDXfc2UMOA@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 8 quoted lines

>> 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.