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

-----Original Message-----
From: rsbecker@nexbridge.com <redacted>
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

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.