不要让你的git碰DSH

今天早上42在 Windows 上从用户主目录(C:\Users\ [user])启动 opencode,启动时一个 git ls-files --others --exclude-standard 子进程烧 50 多秒 CPU 都走不完

于是42开始排查,发现了一些端倪

然后这究竟是怎么出现的呢?

看了dsh源码,以上几行说明每次dsh启动时都会发生的构造指向pnpm install创造的存在junction的环的junction

(在包中,存在这样一对:

store/cordis/node_modules/@deepseek-ai/cordis-plugin-include →(junction) store/cordis-plugin-include
store/cordis-plugin-include/node_modules/@deepseek-ai/cordis   →(junction) store/cordis

)

而在window中,junction作为symlink在win的替代品,对git来说并非像快捷方式而是一个真实目录,所以git会在这一堆junction来回串

当然,ds方面并非没有意识到它的存在

这里都有提到这一问题,但是仅仅解决了junction导致删除而没有解决导致环的问题


现在让我们有请最vb的opencode出场!

opencode一出来就对所在目录一轮git快照

于是…

cordis ──junction──> cordis-plugin-include ──junction──> cordis ──> …
   ^                                                        │
   └──────────────────── 来回串 <────────────────────────────┘

于是git飞起来了

目前的临时补救方法:别让git碰dsh

即: 把~/.dsh/塞进 主目录的 .gitignore


说了这么多,其他的agent难道就不会出问题吗?

很显然,这本质上是git对环没有环检测的问题,因此理论上其他存在git的agent(废话)都有可能中招,那么实际呢?

codex超过5s就会超死,所以不会卡那么久

pi的非递归,只看一层,没有陷入

omp有此类问题,但其实

也是有针对防护,但只是防护了内容过大的问题,function问题没修

kimi-code在进行反馈上报的时候会爆

mimo-code在fork之后没有发现此类问题,也炸了

所以opencode,omp,kimi-code和mimmocode都会出现这一问题,但仅有opencode(+mimocode)会在启动时出现问题

1 个赞

真会有人一行行去看代码啊