On Mon, 2016-05-16 at 20:22 -0700, Stefan Beller wrote: > When using automated tools to find memory leaks, it is hard to > distinguish > between actual leaks and intentional non-cleanups at the end of the > program, > such that the actual leaks hide in the noise. valgrind on git rev-parse HEAD shows: ==21785== definitely lost: 153 bytes in 2 blocks ==21785== indirectly lost: 0 bytes in 0 blocks ==217 85== possibly lost: 0 bytes in 0 blocks ==21785== still reachable: 58,635 bytes in 570 blocks ==21785== suppressed: 0 bytes in 0 blocks AFAIK, nothing in the "definitely lost" category is fixed by your rev-parse patch. I don't think we care that much about "still reachable" memory -- I only care about lost memory. I could imagine, I guess, something that happens to save a pointer to a bunch of memory that should be freed, but I don't think that's the common case. Unless, I guess, you're planning on making a library out of git. Then it would be worth doing much more cleanup. -- 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