Re: [PATCH V5 2/2] git-apply: add --allow-empty flag

Junio C Hamano [off-list ref] 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.