Describe the bug

push_files creates a new server-side commit with a different SHA than an already existing local git commit containing the same changes, and the resulting remote commit may also use different author / committer metadata.

This may be the intended implementation, but it is not clear from the current tool description / README, and it was surprising in a workflow where a local commit had already been created before using push_files.

Affected version

Hosted remote GitHub MCP server

Observed serverInfo.version:
github-mcp-server/remote-57ddf9ca0de2f61fc022ca3cff21efc81a65fc99

I could not map this remote build identifier to a public OSS release tag such as v0.32.0 or v0.33.0.

Steps to reproduce the behavior

1. Create a local git commit in an existing repository.
2. Use push_files to publish the same file changes to the same branch on GitHub.
3. Inspect the resulting commit on GitHub.
4. Compare the remote commit SHA and author / committer metadata with the local git commit.

Expected vs actual behavior

Expected:

• either the docs clearly explain that push_files creates a new server-side commit from file contents and does not preserve a pre-existing local commit SHA / metadata,
• or the tool provides a way to preserve / control commit identity when that matters.

Actual:

• push_files is described very generically as “Push files to repository”
• the resulting commit on GitHub gets a different SHA from the local commit
• the resulting author / committer metadata may differ from the local git commit metadata

Logs

Relevant observation from the resulting remote commit:

• a new commit SHA was created on GitHub instead of reusing the local commit SHA
• the remote commit author / committer metadata differed from the local git commit metadata

I can provide a concrete before/after example if needed.