Git is one of those tools that's so good you forget it's there. The branching model, the distributed history, all of it works so well that it's become invisible infrastructure for basically everyone who writes code.

But recently I've been feeding diffs to LLMs for code review, and I noticed something. When you give a model a git diff, most of what it reads is noise. Context lines, hunk headers, unchanged code that's only there for orientation. The model has to do the same thing a human reviewer does: mentally reconstruct which functions actually changed, and whether those changes matter. It occurred to me that what both the human and the model actually want is the same thing. Not which lines changed, but which semantically meaningful entities changed. Functions, structs, classes. That's the unit everyone thinks in, even if the tools don't show it that way.

So I built a CLI that sits on top of git and diffs code at that level. It uses tree-sitter to parse the AST across 20+ languages, extracts the entities, and shows you exactly which ones were added, modified, or deleted. It also builds a cross-file dependency graph, so you can ask "what breaks if I change this function?" and get a transitive answer across the whole repo.

Curious what the git community thinks. Do you find line-level diffs sufficient for your workflow, or do you also end up mentally translating them into "which functions changed?"

GitHub: [https://github.com/Ataraxy-Labs/sem](https://github.com/Ataraxy-Labs/sem)

Is line-level diffing the right abstraction? Looking for feedback on semantically meaningful diffs