@young1lin/dsh-ui-gitworkbench 0.1.7 → 0.1.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +13 -0
- package/CHANGELOG_EN.md +14 -0
- package/lib/client.js +567 -354
- package/lib/index.js +48 -28
- package/package.json +1 -1
- package/src/client/GitWorkbenchPanel.module.css +4 -0
- package/src/client/GitWorkbenchPanel.tsx +116 -20
- package/src/client/diff-nav.ts +28 -0
- package/src/client/highlight.ts +56 -0
- package/src/client/index.ts +10 -2
- package/src/client/row-window.ts +132 -0
- package/src/client/use-change-nav.ts +19 -9
- package/src/index.ts +46 -25
package/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,19 @@
|
|
|
2
2
|
|
|
3
3
|
本文件记录面向使用者的变更。格式参考 [Keep a Changelog](https://keepachangelog.com/zh-CN/1.1.0/),版本号遵循语义化版本。
|
|
4
4
|
|
|
5
|
+
## [0.1.8] - 2026-08-20
|
|
6
|
+
|
|
7
|
+
紧急修复版:一次点击卡住三秒半,以及 Compare 里看不到内容的文件。
|
|
8
|
+
|
|
9
|
+
### 性能
|
|
10
|
+
|
|
11
|
+
- **打开一个长文件不再卡住界面**。并排 diff 此前把整个文件的每一行都铺进 DOM(两列),shiki 还把每一行单独重新分析一遍着色——开销跟**文件长度**成正比,跟你改了多少行毫无关系。实测两个各只改了 1 行的文件:22 行的花 349ms,4000 行的花 3868ms,其中有**连续 3587ms 页面上什么都不动**,DOM 里 8000 个单元格、112000 个 `<span>`。护栏还允许 20000 行的文件进来,那是这个数的五倍。现在只渲染视口内的行(上下用占位撑住,滚动条仍然是**文件**的长度),两遍 shiki 也只在窗口内跑(向上多读 240 行做上下文,从块注释中间开始的切片也能正确着色)。同一个 4000 行文件:**235ms,最长掉帧 89ms,162 个单元格**。判据不是快了多少倍——15000 行现在 327ms,渲染的还是那 162 个单元格,开销与文件长度脱钩了。400 行以下的文件整体渲染,和以前完全一样。
|
|
12
|
+
- **轮询不再传输一份没人要的补丁**。`stats` 每 3 秒(agent 运行时)跑一次,此前每次都对整个工作树跑 `git diff HEAD` 再截断到 40 万字符。在一个 9 万行改动的工作树上实测:`status` 约 110ms、`--numstat` 约 140ms,而 `git diff HEAD` 要 **595ms 并产出 7.43MB,其中 94.6% 被截断丢弃**。文件树和计数只需要前两个,屏幕上那个文件的 diff 本来就是按需拉的。代价是选中文件时多一次往返,所有仓库都如此——这是刻意的选择:一份"小仓库正确、大仓库悄悄截断"的捆绑补丁是两套行为,而那个阈值从外面根本看不见。
|
|
13
|
+
|
|
14
|
+
### 修复
|
|
15
|
+
|
|
16
|
+
- **Compare 里新增或修改的文件显示不出内容**(XML 尤其明显,同一个文件在 History 和 Files 里都正常)。Compare 把一整块补丁截断到 40 万字符再按文件切分,截断点之后的文件就没有内容了——而单文件按需拉取这条路,Compare **根本没有走**:`fileDiff` 接不了 ref range,代码里明写着这个限制。现在它能接了(`base...head`,无共同祖先时退回两端点 diff,和 Compare 页签本身一致),且不缓存,因为 ref 是会移动的指针。复现仓库里那个文件:问工作区得到 0 字节,问 `base...head` 得到 220877 字节。
|
|
17
|
+
|
|
5
18
|
## [0.1.7] - 2026-08-20
|
|
6
19
|
|
|
7
20
|
### 新增
|
package/CHANGELOG_EN.md
CHANGED
|
@@ -2,6 +2,20 @@
|
|
|
2
2
|
|
|
3
3
|
User-facing changes, newest first. Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); versioning follows SemVer.
|
|
4
4
|
|
|
5
|
+
## [0.1.8] - 2026-08-20
|
|
6
|
+
|
|
7
|
+
An urgent fix release: one click that froze the page for three and a half
|
|
8
|
+
seconds, and files that showed nothing on the Compare tab.
|
|
9
|
+
|
|
10
|
+
### Performance
|
|
11
|
+
|
|
12
|
+
- **Opening a long file no longer freezes the pane.** The side-by-side diff put every line of the whole file into the DOM in two columns, and Shiki re-lexed every one of those lines individually — a cost proportional to the file's LENGTH, with no relation to how much of it changed. Measured on two files with exactly one changed line each: 22 lines cost 349ms, 4,000 lines cost 3,868ms, including **3,587ms during which nothing on the page moved**, with 8,000 cells and 112,000 `<span>`s in the DOM. The guard admits files up to 20,000 lines, five times that again. Only the rows in view are rendered now (spacers stand in for the rest, so the scrollbar is still the length of the FILE), and both Shiki passes run inside that window, with 240 lines of lead-in so a slice starting inside a block comment still lexes in context. The same 4,000-line file: **235ms, worst frame 89ms, 162 cells.** The number that matters is not the ratio — 15,000 lines now costs 327ms and renders the same 162 cells, so the cost is the viewport's rather than the file's. Files of 400 rows or fewer render whole, exactly as before.
|
|
13
|
+
- **The poll stops shipping a patch nobody asked for.** `stats` runs every 3 seconds while an agent is working, and each time it ran `git diff HEAD` over the whole worktree and clipped the result to 400,000 characters. Measured on a worktree with 90,000 changed lines: `status` ~110ms, `--numstat` ~140ms, and `git diff HEAD` **595ms producing 7.43MB, of which the clip discarded 94.6%**. The tree and the counters need only the first two, and the diff of the file actually on screen was already fetched on demand. The trade is one round trip when a file is selected, on every repository — chosen deliberately, because a bundled patch that is correct only below a size threshold is two behaviours, and the threshold is invisible from outside.
|
|
14
|
+
|
|
15
|
+
### Fixed
|
|
16
|
+
|
|
17
|
+
- **Added or modified files showed no content on the Compare tab** (most visibly XML, where the same file read correctly in History and in Files). Compare clips one combined patch at 400,000 characters and splits it per file, so everything past the cut had no content — and the per-file fallback every other tab uses was never taken there: `fileDiff` could not accept a ref range, a limitation the code stated outright. It can now (`base...head`, falling back to the two-tip diff when unrelated histories leave no merge base, exactly as the Compare tab itself does), and deliberately without caching, since a ref name is a moving pointer. On the file in the fixture: asking the working tree returned 0 bytes; asking `base...head` returned 220,877.
|
|
18
|
+
|
|
5
19
|
## [0.1.7] - 2026-08-20
|
|
6
20
|
|
|
7
21
|
### Added
|