-
Notifications
You must be signed in to change notification settings - Fork 3.7k
Description
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
- Create a local git commit in an existing repository.
- Use
push_filesto publish the same file changes to the same branch on GitHub. - Inspect the resulting commit on GitHub.
- 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_filescreates 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_filesis 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.