When upload-sarif runs in a directory that is not a git repository, runGitCommand was calling core.info on every git call failure. Since callers such as getCommitOid and determineBaseBranchHeadCommitOid silently swallow the exception and fall back to environment variables, the same "not a git repository" diagnostic was emitted multiple times per run, adding noise without adding value.

This PR changes the log level in runGitCommand from core.info to core.debug so the full diagnostic is preserved for maintainers with debug logging enabled, but does not appear in normal output. A single core.info fallback notice is added in getCommitOid so callers still see exactly one actionable message when git is unavailable.

Fixes #3383.

Risk assessment

• Low risk: Changes are test-covered, only affect log output levels, and have no impact on action behavior or correctness.

Which use cases does this change impact?

• Third-party analyses - The changes affect the upload-sarif action.

How did/will you validate this change?

• Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files). Existing determineBaseBranchHeadCommitOid tests have been updated to assert core.debug is called instead of core.info. All 30 tests in src/git-utils.test.ts pass.

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

• Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.
• Development/testing only - This change cannot cause any failures in production.

How will you know if something goes wrong after this change is released?

• Other - Log level changes are observable; if users report missing diagnostics, debug logging can be enabled.

Are there any special considerations for merging or releasing this change?

• No special considerations - This change can be merged at any time.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Consider adding a changelog entry for this change.
• Confirm the readme and docs have been updated if necessary.