git_add reports 'Files staged successfully' when nothing was staged
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 74/100
Research direction
Start in src/git/src/mcp_server_git/server.py:132-153 and review the existing git_add tests, which currently cover staging a real change. Reproduce the empty-list and clean-tree cases, then add coverage showing that the reported result matches the index and that an empty file list is handled as specified.
Written by the indexing model from the issue text.
Description
Describe the bug
git_add returns the constant string Files staged successfully regardless of what the index actually took.
src/git/src/mcp_server_git/server.py:132-153:
def git_add(repo: git.Repo, files: list[str]) -> str:
if files == ["."]:
repo.git.add(".")
else:
...
repo.git.add("--", *files)
return "Files staged successfully"
git add exits 0 when it stages nothing, so two calls report success having done nothing:
files: []runsgit add --with no pathspec, which is a no-op. The schema puts no minimum on the list.files: ["."]on a tree with no changes stages nothing.
A nonexistent path is not affected — git add -- nope.txt already fails with "pathspec did not match any files".
The practical failure: an agent computes a file list that comes back empty — a filter, a glob, a diff parse that matched nothing — and passes it. It is told the files are staged. Paired with #4762, it can then stage nothing, commit nothing, and report the work as committed.
To Reproduce
import git
repo = git.Repo(".") # a tracked file, edited but not staged
repo.git.add("--") # files: []
repo.git.diff("--cached", "--name-only") # '' — nothing staged
# git_add returns: "Files staged successfully"
Same on a clean tree with files: ["."]:
tree clean? True
git_add(["."]) -> "Files staged successfully"
actually staged: ''
Expected behavior
An empty files list should be rejected, since it can never stage anything. Otherwise the reported outcome should reflect what the index actually holds, rather than the exit status.
Additional context
No test covers either case; the existing git_add tests all stage a real change first.
- Dominant language
- TypeScript
- Stars
- 90.5k
- Forks
- 11.7k
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 5
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelcontextprotocol/servers
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
modelcontextprotocol/servers#4830 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
modelcontextprotocol/servers#4829 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
modelcontextprotocol/servers#4812 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
modelcontextprotocol/servers#4804 · 1 comment ·
-
README gate confirmation command can be used by any commenter, bypassing the "readme: pending" gate Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
modelcontextprotocol/servers#4796 ·
All issues in modelcontextprotocol/servers
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100