From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 09 Sep 2026 21:39:29 GMT
Subject: Re: [PATCH v3 4/5] promisor-remote: prevent infinite recursion when lazy fetching
Message-ID: <xmqqa4pqp0j2.fsf@gitster.g>
In-Reply-To: <CAP8UFD0WUQX4ts_US2Ehdp7hBmEs1_ztjJiGJMYA2ek4awduMg@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> writes:

> I agree that using a plain "int" seems like the most straightforward,
> but we don't have git_env_int() while we have git_env_ulong().
>
> So would you be fine with something like:
>
>     int depth = (int)git_env_ulong(LAZY_FETCH_DEPTH_ENVIRONMENT, 0);
>
> which is similar to the following in builtin/pack-objects.c:
>
>     name_hash_version = (int)git_env_ulong("GIT_TEST_NAME_HASH_VERSION", 1);
>
> ? Or do you think it's time to introduce git_env_int() in a preparatory patch?

There are 13 existing callers, among which one that you found
explicitly casts to int, but many others make assignments with
implicit cast (e.g., members of bloom_settings used in
commit-graph.c are of type uint32_t), and config.c reads
GIT_TEST_INDEX_THREADS into an "int val" with implicit cast.
progress.c:get_defalut_delay() does the same.

So I would say that it is up to you to pile on existing technical
debt by mimicking config.c:repo_config_get_index_threads() and
progress.c:get_default_delay(), or audit all callers of
git_env_ulong() and migrate appropriate ones among them to use
git_env_int().  From my cursory survey, I suspect that not many
callers of git_get_ulong() would survive.

Thanks.