Re: [PATCH v3 4/5] promisor-remote: prevent infinite recursion when lazy fetching

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 9, 2026, 21:39 UTC
Message-ID: <xmqqa4pqp0j2.fsf@gitster.g>
In-Reply-To: <CAP8UFD0WUQX4ts_US2Ehdp7hBmEs1_ztjJiGJMYA2ek4awduMg@mail.gmail.com>

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

Show 12 quoted lines

> 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.