RE: [Possible Bug] sparse-checkout disable followed by re-init

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Feb 7, 2022, 10:04 UTC
Message-ID: <047a01d81c0a$0f12a340$2d37e9c0$@nexbridge.com>

Show 13 quoted lines

> -----Original Message-----
> From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
> Sent: February 7, 2022 4:57 AM
> To: git@vger.kernel.org
> Subject: [Possible Bug] sparse-checkout disable followed by re-init
> 
> Hi All,
> 
> I noticed a change at 2.35.1 regarding sparse-checkout and am wondering
> whether I am just missing something:
> 
> 1. Create upstream.
> 2. Clone with --no-checkout --depth=1 --filter=blob:none 3.

sparse-checkout init

> 4. sparse-checkout set, with a pattern 5. sparse-checkout list 6. checkout

master

> 7. sparse-checkout reapply 8. sparse-checkout add (up to here, everything

is fine,

> the working area is consistent with the sparsity patterns) 9.

sparse-checkout

> disable (the disable works - I think) 10. sparse-checkout list reports

fatal: this

> worktree is not sparse, which is new in 2.35.1. In 2.34.1, the sparse

patterns are

> reported without error. I think this is incorrect behaviour because the

sparse

> patterns are still configured.
> Then I try to recover
> 11. sparse-checkout init (seems to work - no errors) 12. sparse-checkout

list

> (correctly reports what was previously set/add) 13. sparse-checkout

reapply

> (does nothing apparent - the objects that added to the working area during

the

> disable are still there. My assumption was that the files not matching the

sparsity

Show 20 quoted lines

> patterns would be pruned).
> 
> The .git/config is:
> [core]
>         repositoryformatversion = 1
>         filemode = true
>         bare = false
>         logallrefupdates = true
> [remote "origin"]
>         url = file:///home/randall/stuff/src.git
>         fetch = +refs/heads/master:refs/remotes/origin/master
>         promisor = true
>         partialclonefilter = blob:none
> [branch "master"]
>         remote = origin
>         merge = refs/heads/master
> [extensions]
>         worktreeConfig = true
> 
> My question is, from this point, is there a way to recover the sparsity of

the

> working index (which I expect), or do I have to clone again (not

desirable). This

> seems like a functional change. What is weird to me is that I did not

expect a

> worktreeConfig=true in this situation.
> 
> Thanks,
> Randall

Apologies for the wrapping. Outlook. Argh.