Re: [PATCH] ci(*-leaks): skip the git-svn tests to save time

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Jan 26, 2026, 09:47 UTC
Message-ID: <82b656a5-e5c8-4056-8ec5-4bdab9ef7128@gmail.com>
In-Reply-To: <xmqqqzrggr39.fsf@gitster.g>

On 23/01/2026 17:46, Junio C Hamano wrote:

Show 20 quoted lines

> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>> ... If "git svn" was
>> implemented in C then we probably would want to check it for leaks even
>> though it called a foreign program. That's a long winded way of saying I
>> don't have any better suggestions!
> 
> I am not sure if I agree.  If Perl interpreter used to run the Perl
> version of "git svn" were found leaky, are we willing to go in and
> plug leaks there?  Not likely, particularly since it is not what we
> ship and we do not have control over which version of Perl the users
> have on their systems.  So we say "Perl is foreign and we are not
> equipped to plug leaks in various versions of it on users' systems,
> so it is not worth spending cycles to test for leaks in it".
>
> If "git svn" were in C, linked with libsvn without using the perl
> binding, and libsvn were found leaky, the story is the same.  We do
> not control the version of libsvn the users have on their systems,
> we are not equipped to plug leaks in there, so it is not our job to
> spend cycles to test for leaks in it.

I think that unless the libsvn that linked against was built with -fsanitize=leak we wouldn't find any leaks in it anyway. When I wrote my original mail I was imagining C implementation that forked "svn" but replaced the perl code with C that called the appropriate functions in libgit rather than forking git. In that case I think there's an argument for checking that our code does not leak. Anyway this is all rather hypothetical as we're not likely to rewrite these scripts in C.

Thanks

Phillip