{"thread":{"id":"53697","subject":"sparse-checkout papercuts","startedAt":"2020-06-17T01:38:03Z","lastAt":"2020-06-17T01:38:03Z","messageCount":1,"participants":["Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"399950","messageId":"CABPp-BHzRjcxSfsFSR519VmQfmiwVW=at3VDRJNQMf8rwh9dRA@mail.gmail.com","threadId":"53697","inReplyTo":null,"subject":"sparse-checkout papercuts","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-06-17T01:37:46Z","receivedAt":"2020-06-17T01:38:03Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi everyone,\n\nI just sent off a few series to address some small sparse-checkout\nissues, but there are a couple others that I wasn't sure of a good\ninitial solution for and wanted to solicit ideas from everyone else:\n\nA) Users surprised at left-behind directories after doing a sparse checkout\n\nThis is similar to my \"mention sparsity state in git status\" series I\nsent off, but instead of being about users coming back to a directory\nand having forgotten that they sparsified and then being surprised\nabout files and directories missing, this issue is about users being\nsurprised by directories left around immediately after trying to\nsparsify.\n\nIn particular, after people do some builds in a non-sparse project and\nthen go to sparsify, the .gitignore'd build artifacts are not removed\nwhen all the sources are.  I recently modified my 'sparsify' wrapper,\nso that at the time people go to sparsify they will see a message\nlike:\n\n    $ ./sparsify --modules $module1 $module2 $module 3\n    You are now in a sparse checkout with only 21458 of the 56079 files.\n    Note: You have leftover .gitignore'd files in 33 directories;\n          these likely represent build artifacts.\n          To remove, run: ./sparsify --update --remove-old-ignores\n\nFurther, that special --remove-old-ignores basically runs `git clean\n-fX <directories-outside-sparse-cone>`, where it does some work to\nfigure out which directories are outside the sparse cone, of course.\n\nIs this something that would make sense to add to sparse-checkout\ninit/set?  Should it go in git status instead?  Should git clean get a\nspecial flag for looking just at directories outside of the sparse\ncone (and simplifying my logic in sparsify so it doesn't have to\nhandle this)?  Or is this behavior too specific to our usecases?\n\n\nB) Double updating and unnecessary dirtying of files\n\n`git sparse-checkout` docs say the correct way to get into a sparse\ncheckout is to run the combination of commands:\n   git sparse-checkout init [--cone]\n   git sparse-checkout set $DIR1 $DIR2 ...\n\nUnfortunately, the first step removes virtually all files from the\nworking directory, then the second step (in our case) adds many of\nthem back and sometimes even a majority.  For other wrappers or tools\nthat do dependency analysis between directories and wrap this\nbehavior, this results in behavior that looks like:\n\n   $ ./sparsify --modules maindir1 maindir2\n   Updating files: 100% (56059/56059), done.\n   Updating files: 100% (24853/24853), done.\n   You are now in a sparse checkout with only 24873 of the 56079 files.\n\nThere are three problems here: (1) the user watches two progress bars,\nwhich seems kind of suboptimal.  (2) This process deletes tens of\nthousands of files from the working directory just to immediately add\nthem back.  (3) Adding the files back to the working directory updated\nthe modification timestamps of the files, so any subsequent build they\ninvoke has to rebuild everything present regardless of whether they\nwere up-to-date before sparsifying.\n\nAny ideas or preferences on whether (a) a tool could combine the two\nsparse-checkout commands, (b) specify an extra flag to init that\ndidn't immediately try to apply all the changes to the working tree,\nor (c) something else that'd avoid these problems?\n\n\nThanks,\nElijah\n"}]}