Re: [GSoC PATCH] backfill: auto-detect sparse-checkout from config

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 2, 2026, 16:05 UTC
Message-ID: <xmqqh5pts5zf.fsf@gitster.g>
In-Reply-To: <b7164e46-0521-4c0c-984e-35fc1891e4bd@gmail.com>

Derrick Stolee <stolee@gmail.com> writes:

Show 19 quoted lines

> On 4/1/26 3:31 PM, Trieu Huynh wrote:
>> On Tue, Mar 31, 2026 at 09:59:10AM -0700, Junio C Hamano wrote:
> ...
>>> I am a bit confused by this change.  What's the difference between
>>> using -1 (which you picked) and 1 as the initial value for this
>>> member?  From the proposed log message, I would have expected a new
>>> code that says "ah, we notice, from this member being -1, that the
>>> user did not specify --no-sparse or --sparse, so let's figure out if
>>> our working tree is sparsely checked out ourselves and set it either
>>> to 0 or to 1", but there is nothing like that in the code.
>> ...
>> IMHO, this change set the default value to -1, then it can fallback to
>> repo's config value if user has no-op passing (default to 0 (full
>> backfill if user doesnt intent to config previously either).
>>> Derrick, what do you think?
>
> Indeed, I thought this was how it already worked, as 85127bcdea
> (backfill: assume --sparse when sparse-checkout is enabled,
> 2025-02-03) (introduced in [1]) should have covered.

Ah, OK, in other words, the code to use how the repository is configured when the user does not override from the command line was already there; it was just the way the code checked if the user gave something from the command line was wrong (i.e., initialized to 0, pretending that '--no-foo" was given even when there isn't), and that is why we do not see "ok, there is nothing on the command line, so let's check the repository" _added_ by the patch---because it has always been there. Makes sense.

> The code and commit message do a good job of identifying this bug
> and difference in behavior. The only suggestion I have is to update
> the commit message to point to my original commit that failed to
> implement this behavior in the expected way.

Sounds sensible and makes sense.

Thanks, both.  Let's see a (hopefully small and final) reroll.