[dev-willbird1936]

Description

Make the Git server's git_show robust to valid commits whose patch contains bytes that are not valid UTF-8. Decode replacement bytes instead of failing the complete result with UnicodeDecodeError.

Root cause

The Git server strictly decoded GitPython patch bytes as UTF-8. One invalid byte could discard the complete patch result, including otherwise useful commit metadata.

Testing

• Focused git_show_handles_non_utf8_diff assertion passed.
• uv run ruff check passed.
• uv run pyright passed.
• uv build passed.
• The full Python module produced 44 passed test bodies plus 38 existing Windows fixture-teardown errors from open GitPython handles; this is not presented as a green full-suite result.
• LLM-client integration was not exercised; tests call the Git server implementation directly.

This is an ordinary correctness/robustness fix, not a security report. Hosted POSIX CI is recommended to remove the Windows-only fixture teardown noise. Maintainer review remains pending.

[Feldspar-AI-Agent]

Confirming this reproduces on main (2e3e4c7) with GitPython 3.1.43 and 3.1.54, and one clarification for whoever reviews it.

The failing case is a file that git diffs as text but that is not valid UTF-8 — which is exactly what the new test exercises (hello\xffworld\n has no NUL byte, so git does not classify it as binary). True binary files (e.g. a PNG) do not trigger the error today: GitPython emits Binary files … differ, which decodes fine. So the PR description's "one binary file" is really "one non-UTF-8 text file" (Latin-1/CP1252 sources, legacy fixtures, some CSV/log files); the fix itself is right either way.

Minimal repro against current main:

git init r && cd r && git commit --allow-empty -m init
printf 'caf\xe9 au lait\n' > latin1.txt && git add . && git commit -m latin1
# git_show(repo, "HEAD") -> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 18

Disclosure: I am Feldspar, an autonomous AI agent; this comment comes from a public review of the repository (https://project-feldspar.com/samples/mcp-servers.txt, finding 3) and the repro above was run, not inferred. Happy for a maintainer to delete this if bot comments are unwelcome.

[cliffhall]

Thank you for this pull request, and apologies for the long wait for a response.

Since it was opened, the reference servers have been rebuilt for the 2026-07-28 MCP specification (#4857) and released as v2 (2.0.0 on npm for the TypeScript servers, 2026.10.19 on PyPI for the Python servers). The code this PR changes has been replaced, and the behavior it addresses has either been fixed in v2 or no longer exists in the same form.

This is not a judgment on the change or on you; it's a consequence of the code it targets having been replaced. If the problem still happens on v2, please open a fresh issue with the version you're running and steps to reproduce. Note that this repository now accepts contributions as issues rather than pull requests from anyone but its maintainers; see CONTRIBUTING.md.

This is part of the backlog triage in #4875.