Fix checkout init for SHA-256 repositories

[yaananth]

Summary

Fixes github/actions-runtime#5528 by initializing checkout's local Git repository with the object format used by the target repository.

SHA-256 repositories fail today because checkout creates the local repository with plain git init before fetching. Plain git init creates a SHA-1 repository by default, so the later fetch from a SHA-256 remote fails with a client/server object-format mismatch unless the workflow manually sets GIT_DEFAULT_HASH=sha256.

This PR updates checkout to:

• determine the target repository object format before git init
• use an existing commit SHA directly when checkout already has one
• otherwise call GET /repos/{owner}/{repo}/hash-algorithm
• run git init --object-format=sha256 only when the repository is identified as SHA-256
• preserve checkout's existing default git init behavior for SHA-1 repositories and for cases where the format is not identified

Why this approach

Checkout has to choose the local repository object format before the first fetch. The hash-algorithm endpoint uses the existing action token through Octokit and works before a .git directory exists, so it supports private repositories without setting up Git credential config early.

The endpoint returns hash_algorithm as sha1 or sha256. Checkout uses that value directly instead of inferring the repository format from a branch commit SHA.

When checkout already has a 40- or 64-character commit SHA, it can determine the object format from that SHA without an API request. Otherwise, object-format detection is one pre-init API request to the hash-algorithm endpoint.

Checkout only opts into SHA-256 initialization after a positive SHA-256 result; otherwise it preserves the existing initialization path.

Security notes

The pre-init detection uses the existing Octokit/API authentication path and does not require writing Git credentials before repository initialization. Normal checkout authentication still happens through the existing auth helper flow, including the existing cleanup behavior for persist-credentials: false.

Validation

• npm run build
• npm test -- --runInBand
• npm run format-check
• npm run lint
• unit coverage verifies the GET /repos/{owner}/{repo}/hash-algorithm request and sha1/sha256 responses

[Copilot]

Pull request overview

Fixes checkout for SHA-256 repositories by detecting the target repository's object format before git init and initializing the local repo with --object-format=sha256 when appropriate. Detection uses either the existing commit SHA length (40/64 hex chars) or a pre-init call to GET /repos/{owner}/{repo}/hash-algorithm via the existing action token; SHA-1 and undetermined cases preserve the prior default git init behavior.

Changes:

• Add tryGetRepositoryObjectFormat in github-api-helper.ts (commit-SHA-based or hash-algorithm endpoint).
• Extend git.init() to accept an optional objectFormat and append --object-format=sha256 when applicable.
• Wire detection into git-source-provider.ts before init, and add unit tests + rebuilt dist/index.js.

Show a summary per file

File	Description
src/github-api-helper.ts	Adds RepositoryObjectFormatResult interface, tryGetRepositoryObjectFormat, and getObjectFormat SHA-length helper.
src/git-source-provider.ts	Detects object format prior to repo initialization and passes it to git.init.
src/git-command-manager.ts	Updates init() signature/impl to optionally pass --object-format=sha256.
dist/index.js	Regenerated bundle reflecting the above source changes.
test/github-api-helper.test.ts	New tests covering sha1/sha256/unknown/error responses and SHA-based detection without API calls.
test/git-command-manager.test.ts	New tests verifying git init arguments for sha256 vs sha1 inputs.

Copilot's findings

Tip

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

• Files reviewed: 5/6 changed files
• Comments generated: 1