On Sun, Jun 9, 2013 at 12:38 PM, René Scharfe <rene.scharfe@xxxxxxxxxxxxxx> wrote: > Am 09.06.2013 04:25, schrieb Felipe Contreras: >> It doesn't. I thought you already silently agreed that nobody would >> ever find that leak, as they haven't found the hundreds of leaks that >> plague Git's code. > > Nah, I explained non-silently that leakage was a design decision for > short-running commands that allocate memory, use it and exit. Reusing such > code without freeing allocated memory between runs explicitly turns a "good" > leak into a "bad" one, as we saw with cherry-pick --stdin. git cherry-pick for multiple commits is already there, such a leak would be a bad one, and nobody would find it. Valgrind doesn't know about your concept of "good" leaks, all that you see is tons of leaks. > Any more sequences that we need to guard against, or counterexamples? I don't know. >> In the meantime, just in case, the only sane thing to do is free the >> entries rather than leak. > > I consider not plugging a leak which we don't know how to trigger with > existing code even more sane. Yay, circles! ;-) There's absolutely no benefits to leaving the potential leak. > Let's take it step by step: Once the known leak is plugged we can worry > about the unknown ones. I'll send small patches. Go ahead. I'm not interested any more. -- Felipe Contreras -- 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