Re: leaky cherry-pick
- From
Ramkumar Ramachandra <artagnon@gmail.com>
- Date
- Jan 11, 2012, 09:00 UTC
- Message-ID
- <CALkWK0m+okqJk05BMQAEMww6FNLxaLVhAM92WmUDeA_J-drOdg@mail.gmail.com>
- In-Reply-To
- <7vipki7ix9.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 17 quoted lines
> Ramkumar Ramachandra <artagnon@gmail.com> 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