{"thread":{"id":"57377","subject":"[Possible Bug] sparse-checkout disable followed by re-init","startedAt":"2022-02-07T10:38:05Z","lastAt":"2022-02-09T04:07:56Z","messageCount":2,"participants":["rsbecker@nexbridge.com","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"447875","messageId":"047901d81c09$1fc30eb0$5f492c10$@nexbridge.com","threadId":"57377","inReplyTo":null,"subject":"[Possible Bug] sparse-checkout disable followed by re-init","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-02-07T09:57:26Z","receivedAt":"2022-02-07T10:38:05Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"Hi All,\n\nI noticed a change at 2.35.1 regarding sparse-checkout and am wondering\nwhether I am just missing something:\n\n1. Create upstream.\n2. Clone with --no-checkout --depth=1 --filter=blob:none\n3. sparse-checkout init\n4. sparse-checkout set, with a pattern\n5. sparse-checkout list\n6. checkout master\n7. sparse-checkout reapply\n8. sparse-checkout add (up to here, everything is fine, the working area is\nconsistent with the sparsity patterns)\n9. sparse-checkout disable (the disable works - I think)\n10. sparse-checkout list reports fatal: this worktree is not sparse, which\nis new in 2.35.1. In 2.34.1, the sparse patterns are reported without error.\nI think this is incorrect behaviour because the sparse patterns are still\nconfigured.\nThen I try to recover\n11. sparse-checkout init (seems to work - no errors)\n12. sparse-checkout list (correctly reports what was previously set/add)\n13. sparse-checkout reapply (does nothing apparent - the objects that added\nto the working area during the disable are still there. My assumption was\nthat the files not matching the sparsity patterns would be pruned).\n\nThe .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\nMy question is, from this point, is there a way to recover the sparsity of\nthe working index (which I expect), or do I have to clone again (not\ndesirable). This seems like a functional change. What is weird to me is that\nI did not expect a worktreeConfig=true in this situation.\n\nThanks,\nRandall\n\n\n\n"},{"id":"448030","messageId":"20220209032251.4060572-1-newren@gmail.com","threadId":"57377","inReplyTo":"047901d81c09$1fc30eb0$5f492c10$@nexbridge.com","subject":"Re: [Possible Bug] sparse-checkout disable followed by re-init","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2022-02-09T03:22:51Z","receivedAt":"2022-02-09T04:07:56Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"\nHi Randall,\n\nOn Tue, 7 Feb 2022 04:57:26 -0500, Randall Becker wrote:\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\n\nA quick aside:\n\nYou may want to use --sparse instead of --no-checkout.  The fact that\nthere is no checkout and no index, has caused problems in combination\nwith sparse checkouts before.  In particular, a --no-checkout state is\nhard to distinguish from the user intentionally deleted all files and\nstaging that deletion (i.e. a `git rm -rf .`).  Obviously,\nsparse-checkout shouldn't be undeleting files when the user has staged\nthose deletions, so this is just a confusing state.\n\nThe --sparse flag exists for jumping straight into a sparse-checkout after\nthe clone.\n\nThat said, you suggested that things were fine before your first\ndisable, and my testing of your description seemed to suggest that\nthere wasn't a problem here.  I'd still recommend using --sparse over\n--no-checkout when you want sparse checkouts, though.\n\n> 3. sparse-checkout init\n> 4. sparse-checkout set, with a pattern\n> 5. sparse-checkout list\n> 6. checkout master\n> 7. sparse-checkout reapply\n> 8. sparse-checkout add (up to here, everything is fine, the working area is\n> consistent with the sparsity patterns)\n> 9. sparse-checkout disable (the disable works - I think)\n\nYou can verify with `git ls-files -t`, and looking in the working directory.\nBoth to make sure that the appropriate files are marked with `H` or `S`, and\nthat the working directory matches that specification.\n\n> 10. sparse-checkout list reports fatal: this worktree is not sparse, which\n> is new in 2.35.1. In 2.34.1, the sparse patterns are reported without error.\n> I think this is incorrect behaviour because the sparse patterns are still\n> configured.\n> Then I try to recover\n\nYeah, I'd agree that's incorrect behavior from 2.34.1; there are no\nactive sparsity patterns and we shouldn't mislead by listing them.\nSee 45c5e47048 (\"sparse-checkout: add sanity-checks on initial\nsparsity state\", 2021-12-14) for where the fix was made.\n\n> 11. sparse-checkout init (seems to work - no errors)\n> 12. sparse-checkout list (correctly reports what was previously set/add)\n> 13. sparse-checkout reapply (does nothing apparent - the objects that added\n> to the working area during the disable are still there. My assumption was\n> that the files not matching the sparsity patterns would be pruned).\n\nI would presume that'd be done at the `init` step.  Indeed that's what I\nobserved creating a script that did:\n\n    mkdir testing\n    cd testing\n    $GIT clone --no-checkout --depth=1 --filter=blob:none file:///home/newren/floss/git\n    cd git\n    $GIT sparse-checkout init\n    $GIT sparse-checkout set Documentation\n    $GIT sparse-checkout list\n    $GIT checkout replay\n    $GIT sparse-checkout reapply\n    $GIT sparse-checkout add ci\n    $GIT status\n    $GIT sparse-checkout disable\n    $GIT sparse-checkout list\n    $GIT sparse-checkout init\n    $GIT status\n    $GIT sparse-checkout reapply\n    $GIT status\n    $GIT --version\n\nAnd, in fact the `$GIT status` line at the end reported for me (with\neither git version)\n\n   You are in a sparse checkout with 21% of tracked files present.\n\nAnd a `ls` showed only `Documentation` and `ci` directories.\n\nThe only differences in output for that script for me with git-2.34.1\nand git-2.35.1 was the error message when calling `$GIT\nsparse-checkout list` after the disable step, and the version number\nprinted at the end.\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\n> the working index (which I expect), or do I have to clone again (not\n> desirable).\n\nI'm guessing from your wording that `git ls-files -t` will show a 'S' status\nfor the files you don't want to be present in the working tree, but they are\npresent in the working tree anyway?  I can't duplicate with your instructions\nhere; it seems like there's some other step involved.  However, there are\ncertainly a variety of ways to get into this problematic state.  And, sadly,\nnot a lot of good ways to discover that you have gotten into this state or\ntools for getting out of it.\n\nFixing this class of problems was the purpose of:\n  https://lore.kernel.org/git/pull.1114.v2.git.1642175983.gitgitgadget@gmail.com/\nwhich is still waiting to merge down.\n\n> This seems like a functional change.\n\nThe only functional change I could duplicate from your description was\nthe `git sparse-checkout list` behavior, which was an intentional\nchange.  I suspect there's some other command you ran or maybe an\nill-timed Ctrl-C that got you into the weird state; can you find a\nconsistent way to reproduce?\n\n> What is weird to me is that\n> I did not expect a worktreeConfig=true in this situation.\n\nWe've been setting that with sparse-checkout since the command was\nintroduced (see commit bab3c35908 (\"sparse-checkout: create 'init'\nsubcommand\", 2019-11-21)); and is documented in the sparse-checkout\nmanual.  That's not new at all.\n\n\nHope that helps,\nElijah\n"}]}