Junio C Hamano <gitster@xxxxxxxxx> writes: > Surely, I am sympathetic to the intent. If you are updating "git > frotz" that is sanitizer-clean, and if you write a new test in a > test script that happens to be sanitizer-clean, if you introduced a > new leak to "git frotz", you would appreciate if the CI notices it > and blocks you. > ... > The only time we can sensibly do the "now these are leak-free, and > we will catch and yell at you when you add a new leak" is when we > know _all_ git commands are sanitize clean... There is another scenario where the TEST_PASSES_SANITIZE_LEAK=true may make sense, actually. If we declare that from the time we commit to the approach, until we can mark all the test scripts with the mark, we will put it the sole priority to squash any and all leaks, without doing anything else so that we can finish it the soonest possible. Then it is probably OK to start at 230 and cover all 940 as fast as we can. Because we are effectively closing the tree for anything but plug-leak changes and adding TEST_PASSES_SANITIZE_LEAK=true line to more tests, we wouldn't have to worry about introducing new leaks to existing tests that are marked as already clean---because of the tree closure, they are more likely to stay clean. t4126 wouldn't have gained a new use of format-patch to break it. But of course, such an approach is not feasible in this project, where people do not work in lock-step. That leads to the question I asked at the end of my previous message. > Having said that, what would be the next step to help developers to > avoid introducing new leaks while yelling at them for existing leaks > they did not introduce and not forbidding them to use git subccommands > with existing leaks in their tests? > > I would prefer an approach that does not force the project to make > it the highest priority to plug leaks over everything else. Thanks.
