perf(git): optimize fetch for repos with many tags and branches

[zendesk-slowery23]

Problem

vendir sync is very slow for git repositories with large numbers of branches and tags. The root cause is that the git fetcher unconditionally:

1. Set remote.origin.tagOpt = --tags, causing all tag objects to be downloaded on every fetch
2. Did not pass a refspec to git fetch, causing all remote refs to be negotiated

On a repo with thousands of branches and tags, this turns every sync into a multi-megabyte download regardless of what ref you actually need.

Solution

When a fixed named ref is specified (tag or branch, not a SHA), use a targeted single-refspec fetch:

git fetch origin <ref> --no-tags [--depth N]

Then check out FETCH_HEAD (which git populates from a single-refspec fetch) instead of the ref name.

--tags is kept only where it's actually needed:

• refSelection (semver matching must enumerate all tags)
• Plain SHA refs with no OriginalRef (SHAs can't be fetched by name)

--locked path

--locked substitutes the locked SHA for the original ref before reaching the fetcher, which previously forced a full --tags fetch every time. This PR preserves the original ref in a new unexported OriginalRef field on DirectoryContentsGit (set by Lock(), not serialized to YAML). The fetcher uses it for the same targeted fetch path, then verifies the resulting commit SHA matches the lock — catching force-pushed tags.

Performance

Measured against an internal repo with thousands of branches and hundreds of tags:

Command	Before	After	Improvement
vendir sync	43s	11s	74% faster
vendir sync --locked	1m 26s	9s	89% faster

Changes

• pkg/vendir/config/directory.go — add OriginalRef string (unexported from YAML) to DirectoryContentsGit; set it in Lock() before overwriting Ref with the SHA
• pkg/vendir/fetch/git/git.go — targeted refspec fetch for named refs and locked-SHA-with-OriginalRef; conditional --tags/--no-tags; post-checkout SHA verification in locked mode; isHexSHA() helper
• pkg/vendir/fetch/git/git_test.go — unit tests for each fetch path (named tag, origin/ branch, locked SHA+OriginalRef, plain SHA, depth ordering)
• test/e2e/git_test.go — TestGitFetchOptimizations: verifies targeted fetch line in --json output, locked sync uses OriginalRef, tampered lock SHA is detected

Testing

./hack/build.sh
go test ./pkg/vendir/fetch/git/... -v
VENDIR_BINARY_PATH=./vendir go test ./test/e2e/... -v -run TestGitFetchOptimizations

🤖 Generated with Claude Code

[zendesk-slowery23]

result of go fmt from hack/build.sh

[Copilot]

Pull request overview

This PR speeds up vendir sync for git sources by avoiding full ref negotiation and unconditional tag downloads when only a single named ref is needed, and adds test coverage around the new fetch behaviors (including --locked).

Changes:

• Add an internal OriginalRef field to preserve the pre-lock ref name for optimized fetching in --locked mode.
• Update the git fetcher to use targeted single-refspec fetches and conditionally disable tag fetching.
• Add unit + e2e tests validating fetch command shapes and locked-SHA mismatch detection.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
pkg/vendir/fetch/git/git.go	Implements targeted fetch logic, conditional --tags/--no-tags, FETCH_HEAD checkout handling, and locked SHA verification.
pkg/vendir/config/directory.go	Adds OriginalRef and sets it during Lock() before overwriting Ref with the locked SHA.
pkg/vendir/fetch/git/git_test.go	Adds unit tests covering the new fetch paths and helper utilities for command assertions.
test/e2e/git_test.go	Adds an end-to-end test asserting optimized fetch behavior and tampered lock detection.
pkg/vendir/fetch/http/sync.go	Minor formatting change in basic auth password extraction.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[zendesk-slowery23]

Are any of the maintainers available to approve the workflows for my PR and/or to discuss it? We use vendir pretty heavily and this performance improvement will have a big boost in our engineer's productivity.