Re: What's cooking in git.git (Jan 2022, #03; Thu, 13)

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 14, 2022, 19:47 UTC
Message-ID: <xmqqmtjyaylt.fsf@gitster.g>
In-Reply-To: <CABPp-BFGxKBzi5RYDuiJv6Vz7yyGYTOdJC9cL_EkPGNJ5BksYQ@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 13 quoted lines

> It's apparently the latter, because there have been no test script
> changes in the relevant tests.
>
>> Somebody with too much time on their hand should go in and check to
>> help, before CI testing on 'seen' becomes useful again.
>
> This "fixes" seen:
> https://lore.kernel.org/git/pull.1192.git.git.1642176433017.gitgitgadget@gmail.com/
>
> I briefly looked at a couple leak traces and thought they looked ref
> related, but I don't have time to go hunt down memory leaks right now.
> I figure this thread has reported them, so let's just get "seen" back
> to green.

If it were "we added a use of known-to-leak command in an otherwise clean test, without adding a new leak", I would wholeheartedly support such a change, but if it is the other way around, it may make sense to leave it broken as an incentive for people who care about leaks to go in and fix them up.

If we toggle it off any time leak-checker CI job starts complaining on a test script, the leak-checker CI job serves no useful purpose, no?

An obvious alternative, based on the same attitude, is to rip out the whole fragile leak-checker thing from the CI. I've mentioned an ideal alternative (disregarding feasibility) already elsewhere so I won't repeat it.

Thanks.