git server: git_log accepts a non-positive max_count and a negative value silently returns the entire history
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 55/100
調査の方向性
Start with the git_log argument model and tool schema in src/git, then read the protocol tests in src/git/tests/test_protocol.py. Reproduce the -1 and 0 cases with the in-memory test client, and check that 1 returns one commit. Done when non-positive values produce tool errors and the schema advertises a minimum of 1; the issue reports a prototype and verification, so check whether that work has moved elsewhere before starting.
索引モデルが issue の本文から書いたものです。
説明
{
"title": "git server: git_log accepts a non-positive max_count and a negative value silently returns the entire history",
"body": "### Which server?\n\ngit (mcp-server-git)\n\n### Server version\n\n2026.10.19 (from a clone of this repository at v2/main, commit f18beb74)\n\n### How did you run the server?\n\nFrom a clone of this repository\n\n### Transport\n\nstdio\n\n### Protocol era\n\nLegacy (2025-11-25 or earlier)\n\n### MCP client and version\n\nThe in-memory test client from the mcp SDK used by this repository's own src/git/tests/test_protocol.py (no external client)\n\n### Operating system and runtime\n\nWindows 11, Python 3.13\n\n### Server configuration\n\nBuilt-in test harness from src/git/tests/test_protocol.py, pointing at a temporary git repository.\n\n### Steps to reproduce\n\n1. Start the server against a temporary repository that has 6 commits.\n2. Call the git_log tool with {\"repo_path\": \"<tmp>\", \"max_count\": -1}.\n3. Call it again with {\"repo_path\": \"<tmp>\", \"max_count\": 0}.\n\n### Expected behavior\n\nmax_count is documented as "Maximum number of commits to show", so a value that cannot be a maximum — 0 or negative — should be rejected by the tool's input validation, or at least clamped to something meaningful. Git itself treats any negative -n as "no limit".\n\n### Actual behavior\n\n- max_count: -1 returns all 6 commits with isError: false — the whole history, while reporting success. The parameter is silently ignored, and the effect is the opposite of what the name says.\n- max_count: 0 returns an empty list, also with isError: false.\n- The advertised input schema is {\"default\": 10, \"type\": \"integer\"} with no minimum, so a client cannot know the bound either.\n\nThe value reaches git log -n <value> through GitPython, which is why Git's own interpretation of a negative limit applies.\n\n### Logs or error output\n\n\nmax_count=-1 -> isError=False, commits returned=6 (all of them)\nmax_count=0 -> isError=False, commits returned=0\n\n\n### Already prototyped a fix?\n\nYes — the change is small and I verified it locally, but per CONTRIBUTING.md I am reporting it instead of opening a pull request.\n\nPrompt used (this is the prompt that produced the local change):\n\n> In the src/git Python server of this repository, git_log's max_count parameter has no lower bound. Add Pydantic validation so max_count must be at least 1, with a message that explains the bound, and add the bound to the tool's advertised JSON schema. Add protocol tests that call git_log with -1, 0 and 1 over the in-memory client session and assert that the non-positive values come back as tool errors while 1 returns exactly one commit.\n\nBehavior before and after: before, -1 returned every commit and 0 returned nothing, both as successful results; after, both are rejected by input validation (isError: true, 1 validation error for logArguments) and the schema carries \"minimum\": 1. A valid max_count is unaffected.\n\nHow it was verified: uv run --frozen pytest -q in src/git (189 passed, 3 pre-existing Windows symlink-privilege failures that also fail at the base commit), ruff check, ruff format --check and pyright clean, and the per-file coverage gate (npm run coverage:py -- git) at 100% lines and branches. Red/green was captured by stashing only the source change: 6 failed before, 9 passed after.\n"
}
- 主要言語
- TypeScript
- スター
- 91.6k
- フォーク
- 11.9k
- 平均マージ
- 6時間 37分
- マージ済み PR（30日）
- 147
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
modelcontextprotocol/servers のほかの issue
-
chore v2
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
modelcontextprotocol/servers#5261 ·
メンテナーはふだん 1 日以内に返信
-
docs(git): clarify unconfined default scope and repository confinement options in README and CLIオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
modelcontextprotocol/servers#5231 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
docs(git): clarify unconfined default scope and repository confinement options in README and CLIオープン
難易度 1/5 1時間未満 初心者へのやさしさ 74/100
modelcontextprotocol/servers#5230 ·
メンテナーはふだん 1 日以内に返信
-
git: README should state plainly that without --repository every reachable repository is in scopeオープンdocumentation server-git v2
難易度 1/5 1〜3時間 初心者へのやさしさ 84/100
modelcontextprotocol/servers#5225 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
chore v2
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
modelcontextprotocol/servers#5223 ·
メンテナーはふだん 1 日以内に返信
modelcontextprotocol/servers の issue をすべて見る
似ている issue
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
ajv-validator/ajv#2689 ·
-
[Bug]: IME confirmation Enter can submit the SSH port-forward dialog対応中かも @seijikohara が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
home-assistant/frontend#55323 ·
メンテナーはふだん 1 日以内に返信
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
lingdojo/kana-dojo#33188 · コメント 1 件 · リアクション 5 件 ·
メンテナーはふだん 1 日以内に返信
-
self-driving
難易度 1/5 1〜3時間 初心者へのやさしさ 86/100
メンテナーはふだん 1 日以内に返信