From: Pushkar Singh <pushkarkumarsingh1970@gmail.com>
Date: Mon, 22 Jun 2026 11:35:06 GMT
Subject: [RFC] clone: allow sparse-checkout paths to be specified during clone
Message-ID: <CALE2CrTVVQF4rGhGG-9kmjweFHHYw+xnPU6Jtt=QmHpq7L6P2w@mail.gmail.com>

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