| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat(search): make the workspace index policy visible and correct Vendors flashgrep v0.2.15, aligns BitFun with the daemon's new base-snapshot protocol, and closes the gaps that made the managed index either wrong or inscrutable from the UI. Protocol (breaking upstream change): RepoStatus.rebuild_recommended is gone, replaced by base-delta fields; SearchParams.allow_scan_fallback and the BitFun-only QuerySpec.before_context/after_context are gone too. The old required field would have failed every status-bearing response, so the binary bump and the protocol change land together. The "rebuild recommended" badge becomes "index catching up", driven by base_advance_target_head. Line text: the daemon's four search modes return positions only, so BitFun was rendering line numbers as content ("path:73:line 73"). Content search now goes through search/grouped_line_matches and hydrates text from disk, locally via workspace_search/line_hydration.rs and over SSH via a single batched awk pass (remote_line_hydration.rs) rather than one round trip per file. Both paths share services-core::filesystem::content_preview. Auto-index policy: index only workspaces with roughly 2000+ indexable files. Below that the measured win is 8 ms to 0.2 ms while the index inflates worst (3.3x). The file count is gathered in two commands because --others --exclude-standard costs 4.2 s on chromium against 89 ms for --cached, so the tracked pass returns early once the threshold is met. Builds run through a queue with a cross-workspace disk budget. Policy visibility: the daemon reports needs_index both while the policy is still evaluating and after it declined, so the UI could only hedge. The decision now rides along with the status (WorkspaceIndexStatus.auto_index), and a small workspace reads "no index needed" with the count and threshold instead of an ambiguous sentence that never changes. Remote workspaces have no BitFun-side policy and report None. A workspace that is not a Git worktree can never be indexed, which is a property of the folder rather than a fault, so it stays on the neutral indicator instead of turning red. Grep's -A/-B/-C route to ripgrep, because the daemon has no context-line support and the flags were previously dropped on the wire without a word. ContentSearchRequest loses its context-line fields entirely rather than keeping them unread: a field that looks like it carries context but is silently discarded is exactly how the original defect happened, so the indexed path can no longer express the request at all. | 1 个月前 |