git-clone: sparse checkout no longer uses blobless clone, making it slow for large repos

[knikoloski]

Checklist

• I've searched the issue queue to verify this is not a duplicate bug report.
• I've included steps to reproduce the bug.
• I've pasted the output of kargo version.
• I've pasted logs, if applicable.

Description

Sparse checkout was introduced in v1.9.0 and worked great — our git-clone step completed in ~15 seconds for a 2 GB monorepo.

After upgrading to v1.9.2, the same promotion takes 45+ minutes. It appears the blobless clone filter is no longer being applied, as the full repository is downloaded every time.

We've had to pin to v1.9.0 to keep promotions usable. Is there a timeline for fixing this?

Steps to Reproduce

1. Configure a git-clone step with sparse checkout against a large repository (2 GB+)
2. Run a promotion on v1.9.0 — completes in ~15 seconds
3. Upgrade to v1.9.2 — same promotion takes 45+ minutes

- uses: git-clone
  config:
    repoURL: https://bitbucket.org/example/monorepo.git
    checkout:
      - branch: master
        create: true
        path: ./monorepo
        sparse:
          - charts/app/environments/qa

[krancour]

The change was backed out because it was determined to be the source of significant problems for some paying customers. We'd like to put this back, perhaps as an opt-in thing, but we need to get a better handle first on how this caused the problems that it did.

[knikoloski]

Just checking in on this. I noticed several bugs have been fixed in the newer 1.9.x releases, but we’re unfortunately unable to upgrade from v1.9.0 because of the sparse checkout issue reported here.

Since you mentioned potentially bringing the blobless clone behavior back as an opt-in, that would work well for our use case. Is there any update on plans for that?