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

> Understand Git diff impact mapping with detect changes in codebase-memory-mcp. Learn how it calculates blast radius using knowledge graphs for structured analysis.

- Repository: [Martin Vogel/codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp)
- Tags: internals
- Published: 2026-07-06

---

**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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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:

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

```

The tool returns structured JSON mapping changes to symbols:

```json
{
  "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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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.