dsh-git-statusline

dsh-git-statusline

DSH Web 的紧凑 Git 状态插件，参考 ccstatusline-zh 的 Git widgets。显示位置可在设置页切换：侧边栏底部（默认）、会话顶部标题后方、对话框上方、对话框下方，或关闭。

显示格式：

main (+16,-2) ↑2 ↓1

• (+16,-2)：已暂存和未暂存文本改动的新增/删除行数。
• ↑2：当前分支相对 upstream 待推送的提交数。
• ↓1：当前分支相对 upstream 待拉取的提交数。
• ✓：工作区干净，且相对 upstream 没有领先或落后。
• 无 upstream 时不会显示错误的“已推送”结论，悬停提示会说明无法判断。

显示位置

设置 → Git 状态栏 → 显示位置。选择保存在浏览器 localStorage（键 dsh-git-statusline:config），改完立即生效，无需重启 DSH。

位置	DSH 插槽	形态
侧边栏底部（默认）	sidebar.footer.action	侧边栏一行；收起成 56px 轨道时退化为 ↑ / ↓ / ± / ✓ 单字符
会话顶部标题后方	conversation.session.header.actions	标题栏内的小 chip
对话框上方	conversation.input.dock	输入框上方的 chip，独占一行
对话框下方	conversation.composer.dock	输入框下方状态行内的纯文本
不显示	—	完全不注册插槽，也不发请求

“对话框下方”与 DSH 内置的用量统计、上下文占比同处一行且宽度预算很紧：实测带边框 chip 会把那一行挤到省略号，所以该位置改用无边框纯文本。若在意那一行，建议选“会话顶部标题后方”。

安装

① ② 在 DSH + pnpm 11.21.0 上实测通过，③ 安装的是同一份预构建代码。插件是纯 JavaScript，lib/ 已随仓库提交，不需要任何构建步骤，也不会触发 pnpm 的构建授权提示。

① 从 GitHub 直接安装（推荐）

dsh plugin --profile web add github:pinzza/dsh-git-statusline

② 从本地检出安装（在包含本目录的父目录执行；dsh plugin 会把相对路径锚定到调用目录）

dsh plugin --profile web add ./dsh-git-statusline

③ 从 Release 的预构建 tarball 安装（与 ① 等价，离线也可用）

curl -L -o dsh-git-statusline.tgz \
  https://github.com/pinzza/dsh-git-statusline/releases/latest/download/dsh-git-statusline.tgz
dsh plugin --profile web add ./dsh-git-statusline.tgz

该资产名不含版本号，releases/latest/download/ 会随最新 Release 走，因此不需要在每次发版后改这个链接。想固定版本就用钉住 tag 的形式：.../releases/download/v0.2.0/dsh-git-statusline.tgz。

安装后重启 dsh web。如果 Web 服务由其他进程管理，重启该进程并刷新 http://127.0.0.1:3080。

验证插件层已加载：

dsh --profile web --dump-config | grep -A2 dsh-git-statusline

应能看到 # == dsh-git-statusline 这一层。

卸载：

dsh plugin --profile web remove dsh-git-statusline

验证

node --test        # 在本目录执行：4 个测试

插件每 5 秒固定轮询一次，并在窗口重新获得焦点时立即刷新。同一时刻最多一个进行中的请求（客户端并发去重）。Git 命令均为只读操作，设置 GIT_OPTIONAL_LOCKS=0。

不显示时的排查顺序：① 当前会话的工作目录不是 git 仓库（isRepo=false，插件按设计隐藏）；② DSH 版本。0.1.6-alpha.2 起 sessions.list 的列表快照不再带 current/currentAddress，当前会话改由 uiSession 服务的 current 绑定源暴露（值形如 { key: sessionId }）；lib/client.js 优先读该绑定源，缺失时回退到旧版的 list.current。若升级 DSH 后状态栏消失，先确认浏览器 Network 里是否还有 POST /git-statusline/status——有请求但无渲染即属于情况 ①。

为什么 5 秒轮询不烧 CPU：服务端每次请求先做 mtime 预检（stat .git/HEAD 与 .git/index，毫秒级）——工作区未变直接命中缓存，连 git 进程都不拉起；只有 index/HEAD 变化（如 git add/commit）才真正执行 git。因此轮询本身成本几乎为零，无需事件驱动或长间隔。

性能保护（机制借鉴自 ccstatusline 的 git 缓存设计）：Windows 挂载路径（WSL 的 /mnt/*，即 9P/v9fs/drvfs）上 git 遍历工作树极慢（分钟级），服务端针对慢速文件系统：

• mtime 预检：每次请求先 stat .git/HEAD 与 .git/index（两次 stat，毫秒级）——工作区未变则直接命中缓存，连 git 进程都不拉起；只有 index/HEAD 变化（如 git add/commit）才真正执行 git；
• 超时 90 秒（快路径 5 秒），保证查询能跑完而非被反复杀掉；
• 完整行数统计：diff --numstat 只比较已跟踪文件，实测秒级（远快于 status 的全工作树扫描），因此慢速路径同样返回 (+x,-y)；
• 结果缓存（慢速 60s / 快速 15s，从完成时刻起算；失败/超时只缓存 10s）+ in-flight 去重——同目录并发请求共享一次 git 执行。

因此 Windows 目录下的仓库可以正常显示完整 Git 状态（分支、(+x,-y) 行数、未跟踪数、前后提交数），且工作区未变化时零 git 进程开销。代价是工作区真实变化时首次查询较慢（数秒到一分钟级）。如需更快刷新，仍建议把仓库放在 Linux 原生文件系统（ext4，如 /home）路径下。