Question 1

为什么 code-review-graph 将 Java @Override 方法和 JUnit @BeforeEach 生命周期方法报告为死代码？

Accepted Answer

在 code-review-graph 2.3.8 中，`flows.py` 里的 `_FRAMEWORK_DECORATOR_PATTERNS` 无法识别 Java 的 `@Override` 或 JUnit/TestNG 生命周期注解，因此由 JDK 约定或测试运行器调用的方法会被错误地归类为死代码。

请应用 #1034 中的修复，或手动将以下模式添加到 `flows.py` 中的 `_FRAMEWORK_DECORATOR_PATTERNS`：

然后重新构建并重新运行：

```bash
code-review-graph build --repo . --data-dir /tmp/dc-data
code-review-graph dead-code --repo . --data-dir /tmp/dc-data
```

锚定的 `Override` 模式可防止 `override_settings` 等不相关的注解被误匹配。应用补丁后，`hashCode()` 和 `@BeforeEach setUp()` 不再被报告，而真正未使用的符号仍会被标记。

Question 2

为什么非 ASCII 源文件在 Windows 上的代码审查片段中显示为 mojibake,我该如何修复?

Accepted Answer

这些文件正被以 Windows 系统区域设置编码（通常为 cp1252）而非 UTF-8 进行解码。请修复每个 `open()` 调用，显式传入 `encoding="utf-8"`；仅在需要部分输出的地方保留 `errors="replace"`：

```python
with open(path, encoding="utf-8", errors="replace") as f:
    source = f.read()
```

请将此修复应用于 `tools/review.py`、`tools/flows_tools.py`、`context_savings.py`、`token_benchmark.py`、`eval/runner.py` 和 `eval/reporter.py`。上游修复位于 PR #928，已并入 #988 及合并提交 `3030ca8`；它将包含在下一个版本中。作为 Windows 上的临时解决方法，在运行该工具之前启用 Python UTF-8 模式：

```cmd
set PYTHONUTF8=1
```

PowerShell：

```powershell
$env:PYTHONUTF8 = "1"
```

Question 3

如何修复 code-review-graph build 重建 2.3.8 版本之前的 Windows 图时出现的重复节点问题？

Accepted Answer

这会影响 Windows 上的 code-review-graph 2.3.8。过期文件清理会使用存储的反斜杠路径来选取旧行,但在删除前会将它们规范化为 POSIX 路径,因此没有任何内容被删除,而构建会重新插入每个节点。

修复方法:升级到包含 PR #988 的版本(该修复已合并到 `staging`,并计划在 2.3.8 之后的版本中发布),然后重新运行:

```
code-review-graph build --repo . --data-dir <your-data-dir>
```

修复后的构建会使用旧行存储时的精确拼写将其删除,同时保留规范的 POSIX 行。

如果暂时无法升级,请改为在一个全新的数据目录中进行重建,而不是复用旧目录:

```
code-review-graph build --repo . --data-dir C:/tmp/graph-fresh
```

验证新数据库,然后将你的工具链指向它,或用它替换旧数据目录。在 2.3.8 中,成功的退出码以及正常的 `Full build` 日志行并不能证明已避免重复。

Question 4

如何修复 `code-review-graph tests_for` 对包含测试和 `TESTED_BY` 边的 Python 代码返回 0 个结果的问题？

Accepted Answer

这是 code-review-graph 2.3.8 中的一个 bug。Python 的 `TESTED_BY` 边可能使用裸符号名称，而 `tests_for` 查找的是完全限定路径，例如 `/abs/path/file.py::Class.method`。回退逻辑会将绝对文件路径与点分形式的 Python 模块名（如 `odoo.addons.module.file`）进行比较，因此导入证据检查失败，已被覆盖的代码会被误报为未覆盖。

临时解决方法：使用 `callers_of` 并找出标记为 `is_test=True` 的调用方：

```bash
code-review-graph query callers_of "/abs/path/wizard_update_invoice_supplierinfo_line.py::WizardUpdateInvoiceSupplierinfoLine._prepare_supplierinfo_update"
```

永久修复：升级到包含 PR #960/#988 和 PR #997 中 Python 导入解析修复的版本。如果从源码构建，请使用包含提交 `3030ca8` 和 `9c13f4c` 的构建，或者在修复合并到 `main` 之前从 `staging` 分支构建。该修复会在比较导入证据之前，先将点分 Python 模块名解析为仓库中的实际文件，从而使裸名称回退逻辑能够找到已有的 `TESTED_BY` 边。

Question 5

如何阻止 code-review-graph 的 pre-commit hook 在 git worktree 中创建独立的图数据库？

Accepted Answer

这发生在 code-review-graph 2.3.8 中，因为安装的钩子在运行 `code-review-graph update` 时没有携带 `--repo` 参数。在链接的 worktree 中，仓库发现机制会解析到该 worktree，并创建一个新的 `.code-review-graph` 数据库。

修复已通过 PR #988（合并提交 `3030ca8`）在 `staging` 分支上提供，并将随下一个版本发布。修正后的钩子会传递 `--repo` 参数，并且除非设置了 `CRG_HOOK_WORKTREES=1`，否则会在链接的 worktree 中跳过自动图检查。升级后，请重新安装钩子：

```sh
code-review-graph install
```

针对 2.3.8 的临时解决方案：

1. 打开共享钩子：

```sh
$(git rev-parse --git-path hooks/pre-commit)
```

2. 修改该钩子，使其跳过链接的 worktree，并明确指向主检出：

```sh
#!/bin/sh
if command -v code-review-graph >/dev/null 2>&1; then
  if [ "$(git rev-parse --git-dir)" = "$(git rev-parse --git-common-dir)" ]; then
    code-review-graph update --repo /absolute/path/to/main-checkout || true
    code-review-graph detect-changes --brief --repo /absolute/path/to/main-checkout || true
  fi
fi
```

3. 删除已在 worktree 内创建的数据库：

```sh
rm -rf /path/to/worktree/.code-review-graph
```

作为一次性的替代方案，可以在 worktree 中使用 `git commit --no-verify` 提交，然后在主工作树中运行 `code-review-graph update`。

code-review-graph

项目简介

README 预览

常见问题 (5)

同类型项目

hermes-agent

firecrawl

go

markitdown