Trace: a rename inside an amend or a squash loses the AI line attribution
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start by reading spec issue-3639 R-007 and the Trace README changes and tests in PR #3685; then trace how the push path matches file lines against the session ledger. Reproduce the amend-with-rename flow from the issue and compare it with the separate-rename and amend-only cases. Done means the amended commit is listed as session evidence and hello.txt retains 3 AI lines and 0 human lines, with coverage for the squash case.
由索引模型根据 Issue 内容生成。
描述
A rename inside an amend or a squash of a session commit loses the AI line attribution. All the lines of the renamed file count as human.
Spec issue-3639 R-007 says: "Attribution MUST survive a file rename, amend, rebase, squash, and cherry-pick in the same clone. The CLI MUST match lines by content."
Steps to reproduce
- On a feature branch, an agent session writes
greeting.txtwith three lines, commits it, and pushes. - A human runs
git mv greeting.txt hello.txt, thengit commit --amend --no-edit, thengit push --force.
Expected
The stored session evidence lists the amended commit, and hello.txt has 3 AI lines and 0 human lines.
Actual
The evidence lists the amended commit, but hello.txt has 0 AI lines and 3 human lines.
Cause
The amended commit has no parent that holds greeting.txt, so git sees no rename: the commit creates hello.txt. The ledger of the session holds the line fingerprints under greeting.txt only. The push matches the lines of a file against the ledger of the same path and of the old paths of a rename, so no line of hello.txt matches. A squash that folds a rename into the session commit has the same result.
A rename in a separate commit keeps the AI lines, and an amend with no rename keeps them too.
Evidence
The end-to-end suite found this (spec issue-3635). The first version of the Renames and rewrites check in #3685 used this flow. #3685 documents the gap in the Trace README and tests the amend and the rename separately.
- 主要语言
- Go
- 星标
- 582
- 派生
- 61
- 平均合并
- 12 小时 47 分钟
- 30 天内合并 PR
- 137
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
chainloop-dev/chainloop 的其他 Issue
-
feature-parity trace-provider
难度 2/5 1-3 小时 新手友好度 70/100
chainloop-dev/chainloop#3802 ·
维护者通常 1 天内回复
-
bug trace-provider
难度 4/5 3-5 天 新手友好度 48/100
chainloop-dev/chainloop#3803 ·
维护者通常 1 天内回复
-
feat(trace): support GitHub Copilot (CLI and VS Code) in Chainloop Trace可能已有人在做 @migmartri 今天认领。 未关闭Feature spec trace-provider
chainloop-dev/chainloop#3800 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Allow enabling policy enforcement at the workflow contract level可能已有人在做 @migmartri 于 10 天前认领。 未关闭component/backend new-policy spec
chainloop-dev/chainloop#3762 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
chainloop component/CLI performance trace-provider
难度 4/5 3-5 天 新手友好度 62/100
chainloop-dev/chainloop#3756 ·
维护者通常 1 天内回复
查看 chainloop-dev/chainloop 的全部 Issue
相似的 Issue
-
GitHub webhook is not subscribed to release events, so `event: release` never triggers可能已有人在做 @qsun 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
woodpecker-ci/woodpecker#7542 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
zilliztech/milvus-backup#1386 ·
维护者通常 1 天内回复
-
Pipelined flush no longer observes kill signals after #2042: flush backoffer is built with nil vars未关闭
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
model:sonnet runtime:claude security size:S
难度 2/5 1-3 小时 新手友好度 78/100
FootprintAI/Containarium#3624 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复