{"thread":{"id":"65853","subject":"[RFC] clone: allow sparse-checkout paths to be specified during clone","startedAt":"2026-06-22T11:35:20Z","lastAt":"2026-07-08T17:48:16Z","messageCount":4,"participants":["Pushkar Singh","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"546167","messageId":"CALE2CrTVVQF4rGhGG-9kmjweFHHYw+xnPU6Jtt=QmHpq7L6P2w@mail.gmail.com","threadId":"65853","inReplyTo":null,"subject":"[RFC] clone: allow sparse-checkout paths to be specified during clone","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-06-22T11:35:06Z","receivedAt":"2026-06-22T11:35:20Z","isPatch":false,"body":"Hi,\n\nI had this idea after working on several monorepo-based projects on\nGithub where I only needed to work with certain parts of a repository\nrather than the entire project.\n\nCurrently, the workflow for this is:\n\n    git clone --sparse <repo>\n    cd <repo>\n    git sparse-checkout set <paths>\n\nWhile this works as intended, it feels somewhat cumbersome, especially\nfor someone who is new to Git or not familiar with sparse-checkout\nworkflows.\n\nPersonally, I do not think of the problem as:\n    \"I need to initialize sparse-checkout and then configure pathspecs.\"\n\nInstead, I usually think:\n    \"I only want to clone these directories from the repository.\"\n\nWith that in mind, I was wondering if it would make sense to allow\nsparse-checkout patterns to be specified directly during clone.\n\nFor example:\n    git clone --only=README.md,frontend,tests/frontend <repo>\n\nand optionally supporting exclusions as well:\n\n    git clone \\\n        --only=README.md,frontend,tests \\\n        --except=tests/backend \\\n        <repo>\n\nConsider a repository structured like:\n\n    monorepo/\n    ├── README.md\n    ├── frontend/\n    ├── backend/\n    └── tests/\n            ├── backend/\n            └── frontend/\n\nUsing the command above would result in only:\n\n    README.md\n    frontend/\n    tests/\n    └── frontend/\n\nbeing checked out.\n\nAn alternative interface could be allowing repeated options:\n\n    git clone \\\n        --only=frontend \\\n        --only=tests \\\n        --only=README.md \\\n        --except=tests/backend \\\n        <repo>\n\nbut personally I find the comma-separated form easier to type and read\nfor common monorepo use cases.\n\nThe exact option names are only a suggestion; the primary goal is to\nallow sparse-checkout paths to be specified directly during clone.\n\nMy intention is not to replace sparse-checkout. Internally, this would\nsimply initialize sparse-checkout during clone and then continue using\nthe existing sparse-checkout machinery as usual.\n\nFor implementation, my initial thought was to extend option parsing in\n\"builtin/clone.c\" to accept \"--only\" and \"--except\", split\ncomma-separated values into individual pathspecs, automatically enable\nsparse mode, and then invoke the existing sparse-checkout logic with\nthe resulting patterns.\n\nConceptually, this would be equivalent to performing:\n\n    git sparse-checkout set <pathspecs>\n\nautomatically as part of the clone process.\n\nI would love to hear your thoughts on whether this sounds useful,\nwhether the proposed interface makes sense, and if there are any\nconcerns or alternative approaches I should consider.\n\nThanks,\nPushkar\n"},{"id":"546727","messageId":"CALE2CrTZrwYPOXMkXM993Bjo=bVGZeUKo3kDyuM2sBYg2VC4yg@mail.gmail.com","threadId":"65853","inReplyTo":"CALE2CrTVVQF4rGhGG-9kmjweFHHYw+xnPU6Jtt=QmHpq7L6P2w@mail.gmail.com","subject":"Re: [RFC] clone: allow sparse-checkout paths to be specified during clone","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-06-30T04:02:35Z","receivedAt":"2026-06-30T04:02:52Z","isPatch":false,"body":"Hi,\n\nJust a gentle ping in case this RFC got buried.\n\nIf anyone has any thoughts on the proposal, I'd be happy to hear them.\nI'd mainly like to know whether this seems worth pursuing, or whether\nI should move on to another idea.\n\nThanks,\nPushkar\n"},{"id":"546729","messageId":"20260630053235.GB2495216@coredump.intra.peff.net","threadId":"65853","inReplyTo":"CALE2CrTVVQF4rGhGG-9kmjweFHHYw+xnPU6Jtt=QmHpq7L6P2w@mail.gmail.com","subject":"Re: [RFC] clone: allow sparse-checkout paths to be specified during clone","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-06-30T05:32:35Z","receivedAt":"2026-06-30T05:32:37Z","isPatch":false,"body":"On Mon, Jun 22, 2026 at 05:05:06PM +0530, Pushkar Singh wrote:\n\n> Currently, the workflow for this is:\n> \n>     git clone --sparse <repo>\n>     cd <repo>\n>     git sparse-checkout set <paths>\n> \n> While this works as intended, it feels somewhat cumbersome, especially\n> for someone who is new to Git or not familiar with sparse-checkout\n> workflows.\n> \n> Personally, I do not think of the problem as:\n>     \"I need to initialize sparse-checkout and then configure pathspecs.\"\n> \n> Instead, I usually think:\n>     \"I only want to clone these directories from the repository.\"\n> \n> With that in mind, I was wondering if it would make sense to allow\n> sparse-checkout patterns to be specified directly during clone.\n\nI haven't ever really used sparse-checkout, so I don't have much of an\nopinion. IIRC the sparseness is contained in a patterns file, so I'd\nhave expected the first level of fix to be \"you can provide that file at\nclone time, rather than afterwards\". But maybe nobody really touches\nthat file manually, and they just use the sparse-checkout helper. Like I\nsaid, I don't have any experience. :)\n\nYou might try cc-ing folks who worked on sparse checkouts, especially\nStolee.\n\nOne final thought from a non-sparse-checkout user: you're coming at it\nfrom the point of view of ergonomics (it is annoying to clone and then\nset up sparsity separately) but there is also a performance question. If\nthe clone knows which paths are of interest, would that make it possible\nto request a partial clone of the specific paths?\n\nI think probably not in practice, because most servers have path-based\nfilters disabled (because they're expensive and work against bitmaps).\nSo the strategy is usually more like \"don't ask for any blobs at all,\nand then let checkout lazy-load them as we increase the sparse\ncheckout\". But I'm also not really a partial-clone user, either. ;)\n\n-Peff\n"},{"id":"547517","messageId":"CALE2CrRGvVmAKuhhiv5x-89TqqzA7PrgRANmWQv5NoV7gGVYbQ@mail.gmail.com","threadId":"65853","inReplyTo":"20260630053235.GB2495216@coredump.intra.peff.net","subject":"Re: [RFC] clone: allow sparse-checkout paths to be specified during clone","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-07-08T17:48:03Z","receivedAt":"2026-07-08T17:48:16Z","isPatch":false,"body":"Hi Jeff,\n\nThanks for taking the time to look at this, and sorry for the delayed reply.\n\n> IIRC the sparseness is contained in a patterns file, so I'd have\n> expected the first level of fix to be \"you can provide that file at\n> clone time, rather than afterwards\".\n\nThat's a good point.\n\nMy thinking was mainly from the perspective of someone using the existing\n\"git sparse-checkout\" workflow instead of editing the patterns file\ndirectly. Personally, I've always used \"git sparse-checkout set\" and\nnever really edited the patterns file myself. So I was thinking of this\nas a convenience layer over the existing workflow rather than exposing\nthe patterns file itself.\n\n> You might try cc-ing folks who worked on sparse checkouts, especially\n> Stolee.\n\nThanks for the suggestion! I've cc'd Derrick here in case he has any\nthoughts on this :-)\n\n> One final thought from a non-sparse-checkout user: you're coming at it\n> from the point of view of ergonomics (it is annoying to clone and then\n> set up sparsity separately) but there is also a performance question.\n\nI was mostly thinking about the workflow rather than the performance\nside. My main goal was just to make the workflow a bit simpler and more\nintuitive. Internally, I was still thinking of it as using the existing\nsparse-checkout machinery after clone.\n\nIf there is a way to make use of the selected paths earlier in the clone\nprocess as well, that would definitely be a nice bonus, although I\nhaven't looked into whether that's practical.\n\n> Like I said, I don't have any experience. :)\n\nEven then, I really appreciate you taking the time to read through the\nRFC and share your thoughts :-)\n\nThanks again!\n\n- Pushkar\n"}]}