ivankovic/omnidiff

项目介绍

OmniDiff 是一个 diff 引擎与终端查看器，按文件内容而不是逐行比较。代码文件用 tree-sitter 语法解析后做结构化对比，因此改动会精确标在变化的表达式上，而不是把整行标成删除再加新增。按扩展名可识别 25 种语言；未知的文本扩展名会退回逐行 diff。

对非文本文件，它通过字节判断类型并分别处理：图片按像素比较，动画按帧、字体按字形，压缩包列出变化成员，PDF 按页面渲染，gettext/Qt 消息目录逐条比较。其余二进制文件仍输出一行 Binary file <path> differs 提示。

适合需要审阅代码改动、希望看清一行内部究竟哪里变了，同时想对二进制资产也有可见度的开发者，可配合 Git 或 Jujutsu 使用。

快速使用

用 Cargo 安装（需要 Rust 1.92+，PATH 上有 C 编译器，首次编译需要几分钟）：

cargo install --locked omnidiff

Linux、macOS、Windows 的预编译版本在发布页；Homebrew（brew install ivankovic/omnidiff/omnidiff）、签名 apt 仓库、Nix 以及 Arch/Gentoo 打包配方在文档中也有说明。

直接对比两个文件：

omnidiff BEFORE AFTER

也可以不带参数启动，按 o 选择文件；在查看器内按 ? 查看全部快捷键。

接入 Git 可运行配置向导：

omnidiff git configure

或手工配置：

git config difftool.omnidiff.cmd 'omnidiff "$LOCAL" "$REMOTE"'
git difftool --tool=omnidiff

交互式 TUI 走 git difftool；git diff 和 git log -p 的输出经过管道，始终走文本模式。GIT_EXTERNAL_DIFF=omnidiff git diff 无需 difftool 配置即可使用。

脚本和 CI 中可用 omnidiff --headless BEFORE AFTER 输出纯文本，支持 --context N、--color、--exit-code 和 --mode json。JSON 输出遵循 json_output.schema.json。当 stdout 不是终端时，会自动进入 headless 模式。

支持内容

文本：25 种 tree-sitter 解析语言，包括 C、C++、Rust、Go、Python、JavaScript/TypeScript、Java、Kotlin、Ruby、PHP 等。Markdown、SQL、Protobuf 等会被识别，但按纯文本 diff。

二进制：PNG、JPEG、GIF、WebP、BMP、ICO、TIFF；zip 及其衍生格式（jar、Office、EPUB）、tar、gzip、xz、bzip2；TrueType/OpenType/WOFF/WOFF2/EOT 字体；Windows、X、Hyprland 光标；gettext .mo 与 Qt .qm；PDF。带 BOM 的 UTF-16/UTF-32 按文本读取。

TUI 在终端支持 kitty、sixel 或 iTerm2 协议时直接显示图片，否则使用 Unicode 半块字符；可用 OMNIDIFF_GRAPHICS 覆盖检测结果。

使用约束

• 许可证：AGPL-3.0-only。无法接受 AGPL 源码披露义务的组织可通过 GitHub Sponsors 购买商业许可证。
• 目前不接受贡献：README 说明暂不接受外部贡献，并披露开发中大量使用 AI 辅助（Claude Code）。
• 合并/三方对比：文档只描述双向 diff 与 git difftool、jj 集成；HN 讨论中，三方算法被描述为长期目标。
• 性能数据范围：公开速度数据来自特定笔记本；PDF 的 100ms 内完成率为 57%，压缩包未达到 p99 目标。准确率用手工标注的基准衡量，当前零字节误差的用例为 --full 60.0%、--minimal 69.6%，低于项目自定的 90% 目标。
• Jujutsu 集成必须设置 diff-invocation-mode = "file-by-file"，否则 jj 会传入目录树，调用失败。
• 配套的浏览器审阅工具 codereview 仍是 v0.0.0，README 提示使用需自行承担风险。

HotRepo 点评

项目在 2026-11-03 进入 GitHub Rust 日榜第 7 名，当日新增 300 星；相关 Show HN 讨论（2026-11-01）获得 314 分和 95 条评论。README 的测量写得很细：2,302 个测试用例、覆盖约 7,500 个仓库的 442,530 个代码文件对，并公布 p50/p90/p99 耗时。讨论中有两点值得留意：三方合并尚未实现；「99.95%」的健壮性指标指工具能处理完的文件，其余主要是生成或内嵌的数据块，其他工具同样难以处理。评估时最应关注的是准确率表格。