Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: Trieu Huynh <vikingtc4@gmail.com>,  git@vger.kernel.org
Subject: Re: [GSoC PATCH] backfill: auto-detect sparse-checkout from config
Date: Thu, 02 Apr 2026 09:05:08 -0700	[thread overview]
Message-ID: <xmqqh5pts5zf.fsf@gitster.g> (raw)
In-Reply-To: <b7164e46-0521-4c0c-984e-35fc1891e4bd@gmail.com> (Derrick Stolee's message of "Thu, 2 Apr 2026 10:24:45 -0400")

Derrick Stolee <stolee@gmail.com> writes:

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


      reply	other threads:[~2026-04-02 16:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-31 11:25 [GSoC PATCH] backfill: auto-detect sparse-checkout from config Trieu Huynh
2026-03-31 16:59 ` Junio C Hamano
2026-04-01 19:31   ` Trieu Huynh
2026-04-02 14:24     ` Derrick Stolee
2026-04-02 16:05       ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqh5pts5zf.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=stolee@gmail.com \
    --cc=vikingtc4@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox