mcp-server-git: Make `--repository .` auto-detect git root like standard git commands

[fabn]

Problem

When using mcp-server-git with --repository ., the server uses the literal current working directory instead of finding the git repository root. This differs from standard git behavior and creates portability issues:

1. Breaks when invoked from subdirectories: If the MCP client is launched from a subdirectory of the repository, --repository . points to that subdirectory instead of the repository root, causing failures.

2. Forces absolute paths: Teams must use absolute paths in configuration, requiring each developer to maintain local overrides since everyone has different clone paths.

Current Behavior

{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "."
      ]
    }
  }
}

This only works when the MCP client is launched exactly from the repository root.

Proposed Solution: Make . Auto-detect Repository Root (Preferred)

When --repository . is specified, mcp-server-git should automatically search upward from the current directory to find the git repository root, just like standard git commands do.

Implementation: Use git rev-parse --show-toplevel to find the repository root when the specified path is . or any path within a git repository.

Benefits:

• Matches standard git behavior: Every git command (git status, git log, etc.) works from anywhere inside the repository
• Zero configuration changes needed: Existing configurations with --repository . would just work better
• Team-friendly: Shared configuration works for all developers regardless of:
  • Which subdirectory they're working in
  • Where they cloned the repository
  • Which OS they're using

Alternative Solutions (Less Preferred)

Option 2: Environment Variable Expansion

Allow --repository "${GIT_REPO_ROOT}" but this still requires configuration and environment setup.

Option 3: New Flag

Add --auto-detect-root flag, but this breaks existing configurations and is less intuitive than making . work naturally.

Use Case

We maintain a large IaC repository (~1000 files) with multiple subdirectories (terraform/, applications/, etc.). Team members work in specific subdirectories, and the current behavior forces us to either:

• Always launch the MCP client from root (inconvenient)
• Maintain per-developer absolute paths in local config files (maintenance burden)

Standard git commands work perfectly from any subdirectory—mcp-server-git should too.

Comparison with Standard Git Behavior

# These work from ANY subdirectory within a git repo:
cd /path/to/repo/terraform/environments/production
git status              # ✅ Works - finds repo root automatically
git log                 # ✅ Works - finds repo root automatically

# But mcp-server-git with --repository . does NOT:
mcp-server-git --repository .  # ❌ Uses CWD literally, doesn't find repo root

Would be happy to contribute a PR for this!

[domdomegg]

For 'Forces absolute paths', could this not work with using a path upwards to the repository root if you know how deep you are? E.g. mcp-server-git --repository ../..

[jonathanhefner]

When --repository . is specified, mcp-server-git should automatically search upward from the current directory to find the git repository root, just like standard git commands do.

Is there a reason to special case this behavior to . instead of applying it to any given path?

[fabn]

That's the main use case if one wants to version its mcp.json file. For absolute paths there's no strict need to have that behavior since one would likely point that to git root path.

[FazeelUsmani]

Hi — I'd like to take a shot at this. Based on @jonathanhefner's and @domdomegg's comments, my read is that the fix should generalize: any path the user passes (the CLI --repository arg and the per-tool repo_path arg) should walk up to find the repo root, matching git rev-parse --show-toplevel behavior. GitPython supports this via git.Repo(path, search_parent_directories=True). I'll also make sure the existing validate_repo_path ACL still holds — i.e., the resolved root can't escape --repository's allowed scope. Does that direction sound right?