[ly-wang19]

Description

git_log's timestamp-filtered branch uses the pretty-format %H%n%an%n%ad%n%s%n — note the trailing %n after the subject. With git's inter-commit newline, .split('\n') then yields 5 fields per commit (hash, author, date, subject, ""), but the parser strides in groups of 4 (range(0, len(log_output), 4)).

So only the first commit parses correctly; every subsequent commit is shifted by one — Author shows the next commit's hash, Date shows its author, etc. — producing scrambled git_log output whenever start_timestamp / end_timestamp is used on a repo with 2+ matching commits.

The sibling no-timestamp branch (which uses iter_commits) parses cleanly, establishing the intended one-record-per-commit contract that this branch violates.

Fix

Drop the trailing %n (--format=%H%n%an%n%ad%n%s) so each commit is exactly four newline-delimited fields, matching the groups-of-4 parser.

Testing

Added test_git_log_with_timestamp_filter_parses_each_commit (three commits + a start_timestamp filter): before the fix it fails (messages/authors are shifted into each other); after the fix the three commits parse in order. Full src/git suite: 44 passed.

[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.