feat(git): add explicit Blobless opt-in to BareCloneOptions and CloneOptions

[mail2sudheerobbu-oss]

Summary

Fixes #5725

PR #5677 temporarily disabled --filter=blob:none on all clone operations because some non-GitHub Git servers responded with a "could not fetch from promisor remote" error. This PR restores the filter with a graceful fallback: if a clone with --filter fails because the server does not support partial clones, Kargo automatically retries the clone without the filter, so the operation still succeeds.

Changes

• pkg/controller/git/bare_repo.go: Restore opts parameter (was discarded as _), re-enable --filter when opts.Filter != "", and add a strings.Contains(err, "promisor remote") retry-without-filter fallback.
• • pkg/controller/git/repo.go: Same fix — re-enable --filter in the regular (non-bare) clone path and add the same fallback. Also adds "strings" to the import block.

Behaviour

Server supports partial clone	Result
Yes (GitHub, GitLab, Gitea ≥ 1.20)	Uses --filter=blob:none; significantly faster for large repos with sparse checkout
No (older Bitbucket, self-hosted, etc.)	First attempt fails with "promisor remote" error → retries without --filter → succeeds as before

The fallback only triggers when opts.Filter is set (i.e. when the caller opted into blobless clone). Plain clones are unaffected.

[netlify]

✅ Deploy Preview for docs-kargo-io ready!

Name	Link
🔨 Latest commit	2cdebf6
🔍 Latest deploy log	https://app.netlify.com/projects/docs-kargo-io/deploys/69d44fb6ba5edc000883fcbb
😎 Deploy Preview	https://deploy-preview-6014.docs.kargo.io
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[mail2sudheerobbu-oss]

Hi team — could a maintainer take a look at this PR when you get a chance? The branch is up to date with main and ready for review. Thanks! 🙏

[EronWright]

If we'd prefer a more explicit approach, here's an idea:

Rather than auto-detecting server support reactively, we could expose a blobless field on both GitSubscription and the git-clone step config that users opt into when they know their server supports partial clones:

subscriptions:
  git:
  - repoURL: https://github.com/org/repo
    branch: main
    blobless: true

steps:
- uses: git-clone
  config:
    repoURL: https://github.com/org/repo
    blobless: true
    checkout:
    - branch: main
      path: ./src
      sparse: [some/path]

This would pass --filter=blob:none unconditionally when set, with no retry logic needed. The behavior is fully explicit and predictable — no fragile error-string matching, no wasted first-attempt failures on incompatible servers. But, requires an explicit opt-in (assumedly in combination with sparse:).

[mail2sudheerobbu-oss]

Thank you @EronWright for the thoughtful alternative design suggestion!

Your proposal to add an explicit blobless: true field (or similar) to GitSubscription and the git-clone step config is very clean — it avoids fragile error-string matching, eliminates the wasted first clone attempt, and gives users explicit control over the behavior.

The current approach (reactive fallback) has the advantage of being transparent to existing users — repos already using sparse: or other filters would benefit automatically without any config change. However, as you rightly point out, it does depend on matching an error string, which is brittle.

I think the explicit opt-in approach aligns well with issue #5725's intent. I'm happy to pivot to that design if the team prefers it. It would involve:

1. Adding a blobless (or filterBlobNone) boolean field to GitSubscription and the git-clone step config
2. Passing --filter=blob:none unconditionally when that field is true
3. Removing the error-string matching and retry logic entirely

Would love to hear the team's preference — should I update this PR to implement the explicit opt-in approach?

[krancour]

Given that this was initially backed out in a hurry because of the unanticipated problems it caused many users, the bar for re-enabling this without being an explicit opt-in is going to be very high. If it's an explicit opt-in, it's a much easier thing to entertain -- and sooner rather than later. It even leaves us with the option of declaring the feature beta.

[mail2sudheerobbu-oss]

Thank you @krancour and @EronWright for the clear direction! I'll update this PR to implement the explicit opt-in approach — adding a blobless (or similar) boolean field to GitSubscription and the git-clone step config that passes --filter=blob:none unconditionally when set, and removing the error-string matching / retry logic entirely.

This way users who want blobless clones can opt in explicitly, it can be marked beta if needed, and there's no risk of surprising anyone who didn't ask for it. I'll push the updated implementation shortly.

[mail2sudheerobbu-oss]

Update: Refactored to explicit opt-in (per maintainer feedback)

Per @krancour and @EronWright's feedback, this PR has been refactored away from the reactive error-string-matching retry approach. The new design uses an explicit Blobless bool opt-in field on both BareCloneOptions and CloneOptions.

Changes in this update:

• BareCloneOptions.Filter string → BareCloneOptions.Blobless bool
• CloneOptions.Filter string → CloneOptions.Blobless bool
• When Blobless: true, passes --filter=blob:none unconditionally — no retry logic, no error-string matching
• filterForCheckouts() in git_cloner.go now returns bool instead of string
• Removed all strings.Contains(err, "promisor remote") retry code

The callers that previously set Filter: git.FilterBlobless now set Blobless: true explicitly. Clean intentional opt-in with no implicit fallback.