Skip to content

gen:schema 在锚点「领先于」解析基线时打印「trails the baseline … by 0 key(s)」——方向说反,信息为零 #5847

Description

@baozhoutao

现象

packages/spec/scripts/build-schemas.ts(origin/main 77adf29)第 1313–1323 行,普通 gen:schema / 任何构建在锚点与解析基线不一致时打印:

ℹ️  authorable-surface.base.json trails the baseline at <rev> by <behind> key(s)
   — expected, and not an error: …

behind 的算法是 anchor.keys.filter((k) = 不在 committed 锚点里 ).length(第 1317 行)。当已提交的锚点比本次解析出的基线更新时,解析基线的键是锚点键的子集,于是 behind === 0,输出变成:

ℹ️  authorable-surface.base.json trails the baseline at 9ce056a879ef by 0 key(s)

文件此刻并没有「trail」,它是领先的;而 by 0 key(s) 又把这句话的信息量清零。读者拿到的是一句方向说反、且自相矛盾的提示。

何时可达

正是 #5370 描述的那类状态,并不罕见:

  • merge 停在未 commit 时的任意一次构建 —— merge-base(HEAD, origin/main) 落在分支的旧分叉点,而工作树里的锚点来自 main(os-regen 驱动把该路径解析为 OURS/THEIRS 后就是这个形状);
  • 分支分叉早于锚点推进,随后 git checkout origin/main -- packages/spec/authorable-surface.base.json 或 rebase 带入较新锚点。

实测(#5370 的沙箱夹具,build-schemas-check-mode.test.ts#5370 describe):锚点在 tip、HEAD 分叉于 older 时,gen:schema 退出码 0 并打印上述 by 0 key(s)

影响与定性

纯提示文案,退出码不变、不写文件、无门禁后果 —— 所以按 observation-class 归档,不带 pm:queue。记录理由是:#5370 之后 --update-base 会在这个状态拒绝并解释方向,而同一状态下的普通构建仍在用一句反向措辞描述它,两者读起来会互相矛盾。

可能的修法(不预设)

else if (drifted) 分支里按方向分叉:锚点键 ⊇ 解析基线键时说「锚点比本次解析出的基线新(HEAD 的 merge base 落后于锚点)」,否则维持现有 trails 措辞;或直接复用 #5370 引入的 merge-base --is-ancestor 判定给出方向。

发现于 #5370 的实现过程(PR 里未修,范围外)。

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions