Structural review
Moved and reformatted code stops reading as churn. Changed tokens are highlighted inside their structure, so a big refactor reads as what it did, not as thousands of touched lines.
Tree-sitter structural diffs for more than 60 languages: TypeScript, Python, Rust, Go, Java and the rest. Moved or reformatted code stops reading as churn, changed tokens are highlighted inside their structure, and any file the engine cannot parse falls back, labeled, to the plain patch. The patch stays one toggle away.
A safe review needs to know whether a change rewrote behavior, moved a symbol or only reshaped text. Plain patches remain the source of truth, but semantic analysis can make large refactors easier to inspect.
FluxGit does not claim full semantic diff for every language or file. Semantic views are beta surfaces and must label fallback clearly. When semantic parsing is unavailable, normal Git diff is the correct behavior.
Moved and reformatted code stops reading as churn. Changed tokens are highlighted inside their structure, so a big refactor reads as what it did, not as thousands of touched lines.
When the engine cannot parse a file, the view says so and shows the plain Git diff. "Copy semantic diff" reports per file how many came out structural and how many fell back. I never fabricate a summary.
When an agent proposes a merge, rebase or reset, the approval card opens with a structural summary of what the change does, then a semantic-first diff per file. If a file cannot be parsed, the card says "Structural view unavailable - showing text diff".
Diffs can contain sensitive code. FluxGit treats semantic diff as local app context unless a user deliberately sends content to a configured AI/provider flow or shares diagnostics with consent.