不要让你的git(oc)碰你的DSH

42 2026-08-25 15:42 1

从[preview]不要让你的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)会在启动时出现问题

最新回复 (3)
  • chenastron 08-25 15:46
    1

    是在用户主目录初始化了一个 git 仓库吗?不应该这么做吧

  • 42 楼主 08-25 15:49
    2

    如果正好有一个大**用户直接这样做就会炸,而这本应该被避免

  • 42 楼主 08-26 21:54
    3

    https://linux.do/t/topic/2815902?u=4242


    看不下去看这个

* 帖子来源Linux.do
返回