Re: [RFC] clone: allow sparse-checkout paths to be specified during clone

From: Pushkar Singh <pushkarkumarsingh1970@gmail.com>
Date: Jul 8, 2026, 17:48 UTC
Message-ID: <CALE2CrRGvVmAKuhhiv5x-89TqqzA7PrgRANmWQv5NoV7gGVYbQ@mail.gmail.com>
In-Reply-To: <20260630053235.GB2495216@coredump.intra.peff.net>

Hi Jeff,

Thanks for taking the time to look at this, and sorry for the delayed reply.

> IIRC the sparseness is contained in a patterns file, so I'd have
> expected the first level of fix to be "you can provide that file at
> clone time, rather than afterwards".

That's a good point.

My thinking was mainly from the perspective of someone using the existing "git sparse-checkout" workflow instead of editing the patterns file directly. Personally, I've always used "git sparse-checkout set" and never really edited the patterns file myself. So I was thinking of this as a convenience layer over the existing workflow rather than exposing the patterns file itself.

> You might try cc-ing folks who worked on sparse checkouts, especially
> Stolee.

Thanks for the suggestion! I've cc'd Derrick here in case he has any thoughts on this :-)

> One final thought from a non-sparse-checkout user: you're coming at it
> from the point of view of ergonomics (it is annoying to clone and then
> set up sparsity separately) but there is also a performance question.

I was mostly thinking about the workflow rather than the performance side. My main goal was just to make the workflow a bit simpler and more intuitive. Internally, I was still thinking of it as using the existing sparse-checkout machinery after clone.

If there is a way to make use of the selected paths earlier in the clone process as well, that would definitely be a nice bonus, although I haven't looked into whether that's practical.

> Like I said, I don't have any experience. :)

Even then, I really appreciate you taking the time to read through the RFC and share your thoughts :-)

Thanks again!

- Pushkar