{"thread":{"id":"57376","subject":"RE: [Possible Bug] sparse-checkout disable followed by re-init","startedAt":"2022-02-07T10:06:23Z","lastAt":"2022-02-07T10:06:23Z","messageCount":1,"participants":["rsbecker@nexbridge.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"447874","messageId":"047a01d81c0a$0f12a340$2d37e9c0$@nexbridge.com","threadId":"57376","inReplyTo":null,"subject":"RE: [Possible Bug] sparse-checkout disable followed by re-init","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-02-07T10:04:08Z","receivedAt":"2022-02-07T10:06:23Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"> -----Original Message-----\n> From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>\n> Sent: February 7, 2022 4:57 AM\n> To: git@vger.kernel.org\n> Subject: [Possible Bug] sparse-checkout disable followed by re-init\n> \n> Hi All,\n> \n> I noticed a change at 2.35.1 regarding sparse-checkout and am wondering\n> whether I am just missing something:\n> \n> 1. Create upstream.\n> 2. Clone with --no-checkout --depth=1 --filter=blob:none 3.\nsparse-checkout init\n> 4. sparse-checkout set, with a pattern 5. sparse-checkout list 6. checkout\nmaster\n> 7. sparse-checkout reapply 8. sparse-checkout add (up to here, everything\nis fine,\n> the working area is consistent with the sparsity patterns) 9.\nsparse-checkout\n> disable (the disable works - I think) 10. sparse-checkout list reports\nfatal: this\n> worktree is not sparse, which is new in 2.35.1. In 2.34.1, the sparse\npatterns are\n> reported without error. I think this is incorrect behaviour because the\nsparse\n> patterns are still configured.\n> Then I try to recover\n> 11. sparse-checkout init (seems to work - no errors) 12. sparse-checkout\nlist\n> (correctly reports what was previously set/add) 13. sparse-checkout\nreapply\n> (does nothing apparent - the objects that added to the working area during\nthe\n> disable are still there. My assumption was that the files not matching the\nsparsity\n> patterns would be pruned).\n> \n> The .git/config is:\n> [core]\n>         repositoryformatversion = 1\n>         filemode = true\n>         bare = false\n>         logallrefupdates = true\n> [remote \"origin\"]\n>         url = file:///home/randall/stuff/src.git\n>         fetch = +refs/heads/master:refs/remotes/origin/master\n>         promisor = true\n>         partialclonefilter = blob:none\n> [branch \"master\"]\n>         remote = origin\n>         merge = refs/heads/master\n> [extensions]\n>         worktreeConfig = true\n> \n> My question is, from this point, is there a way to recover the sparsity of\nthe\n> working index (which I expect), or do I have to clone again (not\ndesirable). This\n> seems like a functional change. What is weird to me is that I did not\nexpect a\n> worktreeConfig=true in this situation.\n> \n> Thanks,\n> Randall\n\nApologies for the wrapping. Outlook. Argh.\n \n\n\n"}]}