Hi,

I had this idea after working on several monorepo-based projects on Github where I only needed to work with certain parts of a repository rather than the entire project.

Currently, the workflow for this is:

    git clone --sparse <repo>
    cd <repo>
    git sparse-checkout set <paths>

While this works as intended, it feels somewhat cumbersome, especially for someone who is new to Git or not familiar with sparse-checkout workflows.

Personally, I do not think of the problem as:
    "I need to initialize sparse-checkout and then configure pathspecs."

Instead, I usually think:
    "I only want to clone these directories from the repository."

With that in mind, I was wondering if it would make sense to allow sparse-checkout patterns to be specified directly during clone.

For example:
    git clone --only=README.md,frontend,tests/frontend <repo>

and optionally supporting exclusions as well:

    git clone \
        --only=README.md,frontend,tests \
        --except=tests/backend \
        <repo>

Consider a repository structured like:

    monorepo/
    ├── README.md
    ├── frontend/
    ├── backend/
    └── tests/
            ├── backend/
            └── frontend/

Using the command above would result in only:

    README.md
    frontend/
    tests/
    └── frontend/

being checked out.

An alternative interface could be allowing repeated options:

    git clone \
        --only=frontend \
        --only=tests \
        --only=README.md \
        --except=tests/backend \
        <repo>

but personally I find the comma-separated form easier to type and read for common monorepo use cases.

The exact option names are only a suggestion; the primary goal is to allow sparse-checkout paths to be specified directly during clone.

My intention is not to replace sparse-checkout. Internally, this would simply initialize sparse-checkout during clone and then continue using the existing sparse-checkout machinery as usual.

For implementation, my initial thought was to extend option parsing in "builtin/clone.c" to accept "--only" and "--except", split comma-separated values into individual pathspecs, automatically enable sparse mode, and then invoke the existing sparse-checkout logic with the resulting patterns.

Conceptually, this would be equivalent to performing:

    git sparse-checkout set <pathspecs>

automatically as part of the clone process.

I would love to hear your thoughts on whether this sounds useful, whether the proposed interface makes sense, and if there are any concerns or alternative approaches I should consider.

Thanks, Pushkar

Hi,

Just a gentle ping in case this RFC got buried.

If anyone has any thoughts on the proposal, I'd be happy to hear them. I'd mainly like to know whether this seems worth pursuing, or whether I should move on to another idea.

Thanks, Pushkar

On Mon, Jun 22, 2026 at 05:05:06PM +0530, Pushkar Singh wrote:

I haven't ever really used sparse-checkout, so I don't have much of an opinion. 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". But maybe nobody really touches that file manually, and they just use the sparse-checkout helper. Like I said, I don't have any experience. :)

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

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. If the clone knows which paths are of interest, would that make it possible to request a partial clone of the specific paths?

I think probably not in practice, because most servers have path-based filters disabled (because they're expensive and work against bitmaps). So the strategy is usually more like "don't ask for any blobs at all, and then let checkout lazy-load them as we increase the sparse checkout". But I'm also not really a partial-clone user, either. ;)

-Peff

Hi Jeff,

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

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.

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

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.

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

Thanks again!

- Pushkar