Summary

This PR addresses issue#595 by adding an optionalinclude_sha parameter to theget_file_contents tool, providing a more flexible and performant solution than the previous approach in PR#599.

Problem

Theget_file_contents tool was missing the SHA hash in its response, which is essential for subsequent file update operations usingcreate_or_update_file. The SHA is required by the GitHub API for any update operation.

Solution

Instead of always returning metadata (as in PR#599), this PR adds aninclude_sha boolean parameter that allows users to explicitly choose between:

• Raw content (default): Fast retrieval via GitHub's Raw API
• File metadata: Complete file information including SHA, size, type via Contents API

Key Features

• ✅Backward compatible: Default behavior unchanged
• ✅Performance optimized: Raw API used when metadata not needed
• ✅Flexible: Works for both files and directories
• ✅Comprehensive: Returns complete GitHub API metadata when requested
• ✅Well-tested: Full test coverage for all scenarios

Usage Examples

// Get file content (existing behavior)get_file_contents({owner:"user",repo:"repo",path:"file.md"})// Returns: raw file content// Get file metadata including SHAget_file_contents({owner:"user",repo:"repo",path:"file.md",include_sha:true})// Returns: { name, path, sha, size, type, content, encoding, ... }

Changes Made

• Addedinclude_sha boolean parameter to tool schema
• Updated implementation to conditionally use Contents API vs Raw API
• Enhanced tool description to document new parameter
• Added comprehensive test coverage for all scenarios
• Updated tool snapshots to reflect schema changes

Testing

• ✅ All existing tests pass
• ✅ New test cases cover include_sha functionality
• ✅ Edge cases and error scenarios tested
• ✅ Both file and directory metadata retrieval verified

Supersedes

This PR supersedes#599 by providing a more user-friendly and performant solution to the same problem.

Closes#595
Supersedes#599