Git Diff Impact Mapping: How `detect_changes` Calculates Blast Radius in codebase-memory-mcp

The detect_changes MCP tool transforms raw git diff output into a structured analysis of affected symbols with risk-graded blast radius classifications by leveraging local knowledge graph resolution.

The codebase-memory-mcp repository implements a Model Context Protocol server that bridges git operations with semantic code analysis. Its git diff impact mapping functionality allows developers to preview exactly which functions, classes, and routes will be affected by uncommitted changes, complete with risk assessments that highlight high-impact modifications.

The Three-Stage Impact Detection Pipeline

The detect_changes tool operates through a strictly local pipeline that never executes external commands during analysis. The architecture separates data capture from parsing and semantic resolution.

External diff capture happens before the tool runs. Your CLI or background watcher executes git diff --name-status and git diff --unified=0, feeding the resulting text streams into the parser. This design ensures the binary performs only pure string processing, eliminating shell injection risks and external dependencies.

The parsing layer converts these text streams into structured data structures. Finally, the blast radius calculation maps these structural changes onto the knowledge graph to identify intersecting symbols and assign risk tiers.

Parsing Git Diff Output in pass_gitdiff.c

The file src/pipeline/pass_gitdiff.c implements two specialized parsers that handle different diff formats without invoking git commands.

cbm_parse_name_status() extracts the file-level change matrix. It processes the single-letter status codes (A for added, M for modified, D for deleted, R for renamed) alongside the corresponding file paths. This function gives the system its initial understanding of which files have changed and how.

cbm_parse_hunks() performs the granular line-level analysis. Walking through unified-diff hunks marked by @@ ... @@ headers, this function creates a cbm_changed_hunk_t structure for every edited region. These structures capture the exact line ranges modified within each file, preserving the spatial information needed for symbol intersection testing.

Both parsers expose their functionality through the internal pipeline API declared in src/pipeline/pipeline_internal.h, allowing the MCP layer to consume parsed hunks without handling raw git output directly.

Mapping Changes to Symbols and Risk Classification

The core blast radius calculation resides in src/mcp/mcp.c, where the detect_changes() function orchestrates the transition from text patches to semantic impact analysis.

First, the function receives the parsed file and hunk structures from the pipeline. It queries each changed file against the pre-built knowledge graph (constructed via tree-sitter and hybrid LSP analysis) to resolve which AST nodes—functions, classes, methods, or routes—intersect with the edited line ranges.

For each identified symbol, the tool calculates a risk tier (low, medium, or high) based on three heuristics:

• File type classification: Source code carries higher risk than configuration files, while test files receive modified weighting based on your project structure.
• Call-graph centrality: Functions with high connectivity or those serving as architectural hubs automatically escalate to higher risk tiers due to their broad dependency networks.
• Change type severity: Deletions and renames trigger more aggressive risk classification than pure additions, reflecting the potential for breaking changes.

The final output packages each affected symbol with its file path, precise line ranges, and calculated risk classification—providing a concrete blast radius measurement for the change set.

Using the MCP Tool

You can invoke detect_changes through the CLI or integrated agent interfaces.

Run the tool against your current working tree to analyze uncommitted changes:

codebase-memory-mcp cli detect_changes '{"repo_path":"$(pwd)"}' | jq '.results'

The tool returns structured JSON mapping changes to symbols:

{
  "file": "src/net/http.c",
  "symbol": "handle_request",
  "start_line": 124,
  "end_line": 138,
  "risk": "high"
}

When using supported agents like Claude Code or Codex CLI, natural language queries trigger the tool automatically. Asking "What code did I just modify?" prompts the agent to call detect_changes and surface high-risk functions requiring review.

Summary

• detect_changes in codebase-memory-mcp provides git diff impact mapping that calculates precise blast radius for uncommitted changes.
• The pipeline uses pure string parsers in src/pipeline/pass_gitdiff.c to process git diff --name-status and --unified=0 output without executing shell commands.
• Risk classification (low/medium/high) considers file type, call-graph centrality, and whether changes are additions, deletions, or renames.
• The knowledge graph resolution happens entirely locally through tree-sitter and LSP analysis, requiring no external services.
• Results identify specific symbols (functions, classes, methods) with exact line ranges affected by the diff hunks.

Frequently Asked Questions

How does detect_changes determine which functions are affected by a diff?

The tool uses cbm_parse_hunks() to extract exact line ranges from unified diff output, then queries the local knowledge graph to find which AST nodes (functions, classes, or methods) intersect those line ranges in src/mcp/mcp.c. This mapping relies on the pre-built semantic index rather than text search, ensuring accurate symbol resolution even for complex refactoring operations.

What factors increase the blast radius risk tier?

Risk tiers escalate based on three primary heuristics: call-graph centrality (highly connected functions receive higher risk), change type (deletions and renames rank higher than additions), and file classification (source code changes outrank configuration updates). The implementation in src/mcp/mcp.c weights these factors to classify impact as low, medium, or high.

Does the tool execute git commands internally?

No. The codebase-memory-mcp binary performs only pure string parsing through cbm_parse_name_status() and cbm_parse_hunks() in src/pipeline/pass_gitdiff.c. You must provide the diff text externally (via git diff output captured by your CLI or agent), ensuring the MCP server runs without shell access or external command execution privileges.

Can detect_changes analyze changes that have already been committed?

The tool primarily targets uncommitted changes in the working tree, accepting the diff via standard input or file paths. While the parsers handle any unified diff format, the standard MCP interface documented in the README focuses on pre-commit analysis to catch potential regressions before they enter version control.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}