Tolaria 外部重命名检测机制基于 git diff 的 wikilink 自动修复设计ADR-0036 深度解读【免费下载链接】tolariaDesktop app to manage markdown knowledge bases项目地址: https://gitcode.com/GitHub_Trending/to/tolaria本篇围绕 Tolaria 的架构决策文档 0036-external-rename-detection-via-git-diff.md 展开当笔记文件在应用之外Finder、其他编辑器或git mv被重命名时Tolaria 如何借助 git 的重命名检测能力在窗口重新获得焦点时识别这些变化并通过一条非阻塞横幅引导用户一键修复全库 wikilink。读完后你将理解该机制的完整决策脉络、detect_renames与update_wikilinks_for_renames两个 Tauri 命令的前后端实现细节、git 路径解析的边界处理以及该方案明确的能力边界哪些重命名能检测、哪些不能。背景应用内重命名之外还有一类被忽视的“幽灵重命名”Tolaria 是一个管理 Markdown 知识库的桌面应用vault 中的笔记之间通过[[wikilink]]相互引用。重命名一篇笔记时如果不同步更新其他文件中指向它的 wikilink链接就会全部失效。对于应用内重命名Tolaria 早有完整方案rename.rs负责更新 frontmatter 标题、重命名文件并跨 vault 批量替换 wikilink。但问题在于笔记同样可能被外部重命名用户在 macOS Finder 或文件管理器中直接拖动改名用户在另一个编辑器如 VS Code、Obsidian中重命名文件用户执行git mv old.md new.md等 git 操作。在这三种情况下应用此前没有任何途径感知到重命名已经发生——wikilink 静默断裂vault 关系图变得不一致。ADR-0036 要解决的就是这个问题。决策能选 git 这条路并非偶然Tolaria 已经依赖 git 做 vault 缓存见 ADR-0014 git-based-vault-cache且 git 是 vault 的前置条件见 ADR-0034 git-repo-required-for-vault。git diff因此成为一套“现成、零新增依赖”的检测机制。决策焦点回归时执行 git diff非阻塞横幅提示ADR-0036 的最终决策可以概括为一句话当应用窗口重新获得焦点regain focus时运行git diff --diff-filterR --name-status HEAD来检测自上次提交的 HEAD 以来发生的文件重命名。若发现被重命名的.md文件弹出一条非阻塞横幅“X file(s) renamed — update wikilinks?”。用户接受则触发既有的全库 wikilink 批量替换逻辑复用自 rename.rs忽略则原样关闭横幅。为此新增两个 Tauri 命令detect_renames与update_wikilinks_for_renames。这个设计有三个刻意选择触发时机是“焦点回归”而非“常驻轮询”——用户离开应用去做外部操作Finder、终端、另一个编辑器回来时恰好是最可能产生外部重命名的时刻此时检测一次即可避免持续监听的成本横幅非阻塞且 Ignore 永远可用——用户不会丢失任何工作检测只是建议而非强制修复逻辑复用 rename.rs——不为外部重命名单独写一套替换代码保证“wikilink 批量更新只有一个规范入口”。后端实现detect_renames如何从 git diff 中挖出重命名核心实现位于 src-tauri/src/vault/rename.rs#L598-L643。逐行拆解detect_renames的关键逻辑pub fn detect_renames(vault: Path) - ResultVecDetectedRename, String { let Some(workspace) crate::git::GitWorkspace::resolve(vault)? else { return Ok(Vec::new()); }; let output crate::git::git_command_at(workspace.git_root()) .and_then(|mut command| { command .args([ diff, HEAD, --name-status, --diff-filterR, -M, --, workspace.vault_pathspec(), ]) .output() }) .map_err(|e| format!(Failed to run git diff: {e}))?; if !output.status.success() { return Ok(vec![]); // No HEAD yet or other git issue — no renames } // ... 解析 R 开头的行只保留两端都是 .md 的重命名 }这里有几个值得注意的工程细节1. 实际命令比 ADR 中多了-M参数。ADR 文本写的是git diff --diff-filterR --name-status HEAD源码中实际还显式传了-M开启 rename 检测。--diff-filterR只输出“重命名”类别的条目--name-status使输出按R100\t旧路径\t新路径的制表符分隔格式呈现便于逐行解析。2. 用 pathspec 把 diff 范围限制在 vault 内。workspace.vault_pathspec()来自 src-tauri/src/git/workspace.rs 中的GitWorkspace::resolve它通过git rev-parse --show-prefix判断 vault 目录是否嵌套在一个更大的 git 仓库里比如 vault 是某个 monorepo 的docs/子目录。若是则 pathspec 为docs/diff 只对比 vault 子树解析函数vault_relative_path再负责把仓库相对路径还原为 vault 相对路径见 workspace.rs#L88-L97。这样“父仓库里的其他文件被改名”不会污染检测结果。3. 双重优雅降级。两处失败路径都返回空列表而不是错误vault 不是 git 仓库GitWorkspace::resolve返回None时直接返回Ok(Vec::new())git diff HEAD执行失败例如仓库还没有任何提交HEAD 不存在时也返回空列表。这与 Tolaria 后来支持非 git vault 的演进ADR-0085 non-git-vault-support保持一致检测机制静默失效不报错、不打扰。4. 只关心.md文件。解析阶段要求R状态行的旧、新路径都以.md结尾附件、配置等其他文件的重命名被过滤掉。测试代码对这两条边界做了明确验证rename.rs#L843-L886 中test_detect_renames_preserves_chinese_markdown_paths验证了开启core.quotePath后中文文件名旧名.md→新名.md能被正确解析test_detect_renames_in_nested_vault_excludes_parent_files验证了嵌套 vault 场景下父仓库文件的重命名不会混入结果。修复逻辑update_wikilinks_for_renames复用 rename.rs 的规范入口Tauri 命令层定义在 src-tauri/src/commands/vault/rename_cmds.rs#L267-L281detect_renames是 async 命令用tokio::task::spawn_blocking把阻塞的 git 子进程调用移到线程池避免卡住异步运行时update_wikilinks_for_renames则接收vaultPath和一组DetectedRename { old_path, new_path }返回更新的文件总数。真正的替换逻辑在 rename.rs#L645-L667。对每条检测到的重命名它做三件事构造“旧目标集合”。wikilink 可能指向标题、也可能指向路径 stemcollect_legacy_wikilink_targetsrename.rs#L142-L145会收集旧标题由文件名 stem 反推 Title Case、旧路径 stem、旧文件名 stem 三种候选走与在应用内重命名完全相同的替换管线update_wikilinks_in_vault先用build_wikilink_patternrename.rs#L87-L99构造匹配[[旧目标]]/[[旧目标|别名]]的正则再遍历 vault 全部.md文件逐个替换并回写最后汇总updated_files与failed_updates计数累计总数返回给前端用于 toast 提示。ADR 中“rename.rs从此成为应用内重命名与外部重命名恢复共享的规范入口”这一后果在代码里可以直接验证应用内重命名finalize_rename与外部修复update_wikilinks_for_renames调用的是同一个update_wikilinks_in_vault替换语义完全一致。端到端验证见 rename_cmds.rs#L394-L435 的测试先初始化 git 仓库并提交笔记fs::rename改名后git add -A再调用detect_renames断言拿到project-plan.md → plans.md的映射最后调用update_wikilinks_for_renames确认链路贯通。前端实现焦点监听 非阻塞横幅前端由两部分组成均位于仓库src/下1. useVaultRenameDetection.ts 钩子。它在vaultPath变化时向window注册focus监听器第 25-38 行const handleFocus () { invokeDetectedRename[](detect_renames, { args: { vaultPath } }) .then((renames) { if (renames.length 0) setDetectedRenames(renames) }) .catch((err) console.warn([vault] Git rename detection failed:, err)) } window.addEventListener(focus, handleFocus)注意两个降级策略非 Tauri 环境如浏览器中跑前端测试直接跳过detect_renames调用失败只console.warn不打扰用户。用户点击 “Update wikilinks” 后handleUpdateWikilinks调用update_wikilinks_for_renames成功后清空横幅、调用reloadVault()刷新 vault 索引并用 toast 报告 “Updated wikilinks in N files”第 40-53 行。2. RenameDetectedBanner.tsx 横幅组件。当renames.length 0时组件返回null不渲染否则展示 “N file(s) renamed outside Tolaria. Update wikilinks?” 以及 “Update wikilinks” / “Ignore” 两个按钮其中 Ignore 就是调用handleDismissRenames清空状态——对应 ADR 中“忽略即关闭、不做任何修改”的语义。横幅通过App.tsx集成到主界面src/App.tsx#L1851组件行为有 RenameDetectedBanner.test.tsx 覆盖。备选方案对比为什么不用文件系统监听或扫描断链ADR 记录了三个候选方案的权衡这也是理解该设计取舍的关键方案思路优点缺点A选中焦点回归时跑git diff非阻塞横幅复用既有 git 基础设施非侵入用户保留控制权只能检测 git 跟踪到的重命名staged 或已提交纯 Finder 改名且完全绕过 git 的查不到BFSEvents/ 文件系统 watcher 监听 rename 事件无论是否走 git 都能抓到所有重命名显著更复杂需要 Rust 异步机制编辑器临时文件会造成误报且该增强被单独规划C焦点回归时全库扫描断链正确O(n) 且“噪音大”扫出断链也不知道新文件名是什么无法自动修复方案 C 的致命伤是信息量不足扫到一个[[old-name]]找不到目标却不知道目标改名叫了什么只能提示而不能修复方案 B 则与“git 是 vault 前置条件”的现状叠加了不必要的复杂度。方案 A 在“检测精度—实现成本—用户体验”之间取得了最平衡的落点。影响与能力边界这套机制明确不做什么ADR 的 Consequences 一节划清了机制的边界对照源码均可证实重命名必须被 git 感知。--diff-filterR依赖 git 的重命名检测staged 或相对 HEAD 的工作区变化git mv这类未提交的重命名能被抓到而完全绕开 git 的 Finder 改名不在检测范围内。这是方案 A 的核心 trade-off被如实记录而非掩盖。每次焦点激活有一次轻量 shell 调用开销。git diff HEAD本身很快但每次窗口激活都会产生一次 git 进程调用ADR 明确认为这在典型 vault 规模下可接受。横幅永远可忽略。用户不会因该机制丢失任何数据“Ignore” 路径只做状态清理前端setDetectedRenames([])不触碰磁盘。预留了升级路径。ADR 最后一条写明若未来 FS 级重命名检测不依赖 git成为优先级本机制将退为兜底而非主策略——这与 ADR-0089 active-vault-filesystem-watcher 后续引入文件系统监听器、以及 ADR-0075 crash-safe-note-rename-transactions 将重命名写入做成可恢复事务的演进方向是呼应的git diff 检测负责“发现”rename 事务层负责“安全地改”。动手验证一条命令复现完整链路在任意 Tolaria vault 中可以用以下步骤复现 ADR 描述的检测流程# 1. 正常提交一次建立 HEAD 基线 git add -A git commit -m baseline # 2. 外部重命名一篇笔记并暂存 git mv old-note-name.md new-note-name.md git add -A # 3. 此时切到终端外、把 Tolaria 窗口切到后台再切回来 # 应用重新获得焦点时会执行 git diff HEAD --name-status --diff-filterR -M # 输出应包含R100\told-note-name.md\tnew-note-name.md # 4. 应用横幅出现 “1 file renamed outside Tolaria. Update wikilinks?” # 点击 “Update wikilinks” 后全库指向 [[old-note-name]] 的 wikilink # 会被批量替换为 [[new-note-name]]toast 报告更新的文件数如果 vault 嵌套在父仓库中vault 不是.git所在目录第 3 步的 diff 会自动加上 pathspec 限定如-- docs/保证只统计 vault 子树内的重命名——这一点由GitWorkspace::resolve与嵌套 vault 测试用例保证。小结ADR-0036 展示了一个典型的“低成本高收益”架构决策面对“外部重命名导致 wikilink 断裂”的问题Tolaria 没有引入文件系统监听这类重武器而是复用 vault 本就依赖的 git用一次git diff --diff-filterR加上两个 Tauri 命令、一个焦点监听钩子和一条非阻塞横幅实现了“检测—确认—批量修复”的完整闭环。其关键工程实践包括-M显式启用 rename 检测、pathspec 限定 vault 子树、非 git 场景静默降级、旧标题/路径 stem 多目标匹配的兼容替换以及把外部修复与应用内重命名收敛到 rename.rs 的同一替换入口。对于任何需要检测 git 仓库中文件移动的桌面/编辑器类应用这套模式都是可以直接借鉴的参考。【免费下载链接】tolariaDesktop app to manage markdown knowledge bases项目地址: https://gitcode.com/GitHub_Trending/to/tolaria创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Tolaria 外部重命名检测机制：基于 git diff 的 wikilink 自动修复设计（ADR-0036 深度解读）
Tolaria 外部重命名检测机制基于 git diff 的 wikilink 自动修复设计ADR-0036 深度解读【免费下载链接】tolariaDesktop app to manage markdown knowledge bases项目地址: https://gitcode.com/GitHub_Trending/to/tolaria本篇围绕 Tolaria 的架构决策文档 0036-external-rename-detection-via-git-diff.md 展开当笔记文件在应用之外Finder、其他编辑器或git mv被重命名时Tolaria 如何借助 git 的重命名检测能力在窗口重新获得焦点时识别这些变化并通过一条非阻塞横幅引导用户一键修复全库 wikilink。读完后你将理解该机制的完整决策脉络、detect_renames与update_wikilinks_for_renames两个 Tauri 命令的前后端实现细节、git 路径解析的边界处理以及该方案明确的能力边界哪些重命名能检测、哪些不能。背景应用内重命名之外还有一类被忽视的“幽灵重命名”Tolaria 是一个管理 Markdown 知识库的桌面应用vault 中的笔记之间通过[[wikilink]]相互引用。重命名一篇笔记时如果不同步更新其他文件中指向它的 wikilink链接就会全部失效。对于应用内重命名Tolaria 早有完整方案rename.rs负责更新 frontmatter 标题、重命名文件并跨 vault 批量替换 wikilink。但问题在于笔记同样可能被外部重命名用户在 macOS Finder 或文件管理器中直接拖动改名用户在另一个编辑器如 VS Code、Obsidian中重命名文件用户执行git mv old.md new.md等 git 操作。在这三种情况下应用此前没有任何途径感知到重命名已经发生——wikilink 静默断裂vault 关系图变得不一致。ADR-0036 要解决的就是这个问题。决策能选 git 这条路并非偶然Tolaria 已经依赖 git 做 vault 缓存见 ADR-0014 git-based-vault-cache且 git 是 vault 的前置条件见 ADR-0034 git-repo-required-for-vault。git diff因此成为一套“现成、零新增依赖”的检测机制。决策焦点回归时执行 git diff非阻塞横幅提示ADR-0036 的最终决策可以概括为一句话当应用窗口重新获得焦点regain focus时运行git diff --diff-filterR --name-status HEAD来检测自上次提交的 HEAD 以来发生的文件重命名。若发现被重命名的.md文件弹出一条非阻塞横幅“X file(s) renamed — update wikilinks?”。用户接受则触发既有的全库 wikilink 批量替换逻辑复用自 rename.rs忽略则原样关闭横幅。为此新增两个 Tauri 命令detect_renames与update_wikilinks_for_renames。这个设计有三个刻意选择触发时机是“焦点回归”而非“常驻轮询”——用户离开应用去做外部操作Finder、终端、另一个编辑器回来时恰好是最可能产生外部重命名的时刻此时检测一次即可避免持续监听的成本横幅非阻塞且 Ignore 永远可用——用户不会丢失任何工作检测只是建议而非强制修复逻辑复用 rename.rs——不为外部重命名单独写一套替换代码保证“wikilink 批量更新只有一个规范入口”。后端实现detect_renames如何从 git diff 中挖出重命名核心实现位于 src-tauri/src/vault/rename.rs#L598-L643。逐行拆解detect_renames的关键逻辑pub fn detect_renames(vault: Path) - ResultVecDetectedRename, String { let Some(workspace) crate::git::GitWorkspace::resolve(vault)? else { return Ok(Vec::new()); }; let output crate::git::git_command_at(workspace.git_root()) .and_then(|mut command| { command .args([ diff, HEAD, --name-status, --diff-filterR, -M, --, workspace.vault_pathspec(), ]) .output() }) .map_err(|e| format!(Failed to run git diff: {e}))?; if !output.status.success() { return Ok(vec![]); // No HEAD yet or other git issue — no renames } // ... 解析 R 开头的行只保留两端都是 .md 的重命名 }这里有几个值得注意的工程细节1. 实际命令比 ADR 中多了-M参数。ADR 文本写的是git diff --diff-filterR --name-status HEAD源码中实际还显式传了-M开启 rename 检测。--diff-filterR只输出“重命名”类别的条目--name-status使输出按R100\t旧路径\t新路径的制表符分隔格式呈现便于逐行解析。2. 用 pathspec 把 diff 范围限制在 vault 内。workspace.vault_pathspec()来自 src-tauri/src/git/workspace.rs 中的GitWorkspace::resolve它通过git rev-parse --show-prefix判断 vault 目录是否嵌套在一个更大的 git 仓库里比如 vault 是某个 monorepo 的docs/子目录。若是则 pathspec 为docs/diff 只对比 vault 子树解析函数vault_relative_path再负责把仓库相对路径还原为 vault 相对路径见 workspace.rs#L88-L97。这样“父仓库里的其他文件被改名”不会污染检测结果。3. 双重优雅降级。两处失败路径都返回空列表而不是错误vault 不是 git 仓库GitWorkspace::resolve返回None时直接返回Ok(Vec::new())git diff HEAD执行失败例如仓库还没有任何提交HEAD 不存在时也返回空列表。这与 Tolaria 后来支持非 git vault 的演进ADR-0085 non-git-vault-support保持一致检测机制静默失效不报错、不打扰。4. 只关心.md文件。解析阶段要求R状态行的旧、新路径都以.md结尾附件、配置等其他文件的重命名被过滤掉。测试代码对这两条边界做了明确验证rename.rs#L843-L886 中test_detect_renames_preserves_chinese_markdown_paths验证了开启core.quotePath后中文文件名旧名.md→新名.md能被正确解析test_detect_renames_in_nested_vault_excludes_parent_files验证了嵌套 vault 场景下父仓库文件的重命名不会混入结果。修复逻辑update_wikilinks_for_renames复用 rename.rs 的规范入口Tauri 命令层定义在 src-tauri/src/commands/vault/rename_cmds.rs#L267-L281detect_renames是 async 命令用tokio::task::spawn_blocking把阻塞的 git 子进程调用移到线程池避免卡住异步运行时update_wikilinks_for_renames则接收vaultPath和一组DetectedRename { old_path, new_path }返回更新的文件总数。真正的替换逻辑在 rename.rs#L645-L667。对每条检测到的重命名它做三件事构造“旧目标集合”。wikilink 可能指向标题、也可能指向路径 stemcollect_legacy_wikilink_targetsrename.rs#L142-L145会收集旧标题由文件名 stem 反推 Title Case、旧路径 stem、旧文件名 stem 三种候选走与在应用内重命名完全相同的替换管线update_wikilinks_in_vault先用build_wikilink_patternrename.rs#L87-L99构造匹配[[旧目标]]/[[旧目标|别名]]的正则再遍历 vault 全部.md文件逐个替换并回写最后汇总updated_files与failed_updates计数累计总数返回给前端用于 toast 提示。ADR 中“rename.rs从此成为应用内重命名与外部重命名恢复共享的规范入口”这一后果在代码里可以直接验证应用内重命名finalize_rename与外部修复update_wikilinks_for_renames调用的是同一个update_wikilinks_in_vault替换语义完全一致。端到端验证见 rename_cmds.rs#L394-L435 的测试先初始化 git 仓库并提交笔记fs::rename改名后git add -A再调用detect_renames断言拿到project-plan.md → plans.md的映射最后调用update_wikilinks_for_renames确认链路贯通。前端实现焦点监听 非阻塞横幅前端由两部分组成均位于仓库src/下1. useVaultRenameDetection.ts 钩子。它在vaultPath变化时向window注册focus监听器第 25-38 行const handleFocus () { invokeDetectedRename[](detect_renames, { args: { vaultPath } }) .then((renames) { if (renames.length 0) setDetectedRenames(renames) }) .catch((err) console.warn([vault] Git rename detection failed:, err)) } window.addEventListener(focus, handleFocus)注意两个降级策略非 Tauri 环境如浏览器中跑前端测试直接跳过detect_renames调用失败只console.warn不打扰用户。用户点击 “Update wikilinks” 后handleUpdateWikilinks调用update_wikilinks_for_renames成功后清空横幅、调用reloadVault()刷新 vault 索引并用 toast 报告 “Updated wikilinks in N files”第 40-53 行。2. RenameDetectedBanner.tsx 横幅组件。当renames.length 0时组件返回null不渲染否则展示 “N file(s) renamed outside Tolaria. Update wikilinks?” 以及 “Update wikilinks” / “Ignore” 两个按钮其中 Ignore 就是调用handleDismissRenames清空状态——对应 ADR 中“忽略即关闭、不做任何修改”的语义。横幅通过App.tsx集成到主界面src/App.tsx#L1851组件行为有 RenameDetectedBanner.test.tsx 覆盖。备选方案对比为什么不用文件系统监听或扫描断链ADR 记录了三个候选方案的权衡这也是理解该设计取舍的关键方案思路优点缺点A选中焦点回归时跑git diff非阻塞横幅复用既有 git 基础设施非侵入用户保留控制权只能检测 git 跟踪到的重命名staged 或已提交纯 Finder 改名且完全绕过 git 的查不到BFSEvents/ 文件系统 watcher 监听 rename 事件无论是否走 git 都能抓到所有重命名显著更复杂需要 Rust 异步机制编辑器临时文件会造成误报且该增强被单独规划C焦点回归时全库扫描断链正确O(n) 且“噪音大”扫出断链也不知道新文件名是什么无法自动修复方案 C 的致命伤是信息量不足扫到一个[[old-name]]找不到目标却不知道目标改名叫了什么只能提示而不能修复方案 B 则与“git 是 vault 前置条件”的现状叠加了不必要的复杂度。方案 A 在“检测精度—实现成本—用户体验”之间取得了最平衡的落点。影响与能力边界这套机制明确不做什么ADR 的 Consequences 一节划清了机制的边界对照源码均可证实重命名必须被 git 感知。--diff-filterR依赖 git 的重命名检测staged 或相对 HEAD 的工作区变化git mv这类未提交的重命名能被抓到而完全绕开 git 的 Finder 改名不在检测范围内。这是方案 A 的核心 trade-off被如实记录而非掩盖。每次焦点激活有一次轻量 shell 调用开销。git diff HEAD本身很快但每次窗口激活都会产生一次 git 进程调用ADR 明确认为这在典型 vault 规模下可接受。横幅永远可忽略。用户不会因该机制丢失任何数据“Ignore” 路径只做状态清理前端setDetectedRenames([])不触碰磁盘。预留了升级路径。ADR 最后一条写明若未来 FS 级重命名检测不依赖 git成为优先级本机制将退为兜底而非主策略——这与 ADR-0089 active-vault-filesystem-watcher 后续引入文件系统监听器、以及 ADR-0075 crash-safe-note-rename-transactions 将重命名写入做成可恢复事务的演进方向是呼应的git diff 检测负责“发现”rename 事务层负责“安全地改”。动手验证一条命令复现完整链路在任意 Tolaria vault 中可以用以下步骤复现 ADR 描述的检测流程# 1. 正常提交一次建立 HEAD 基线 git add -A git commit -m baseline # 2. 外部重命名一篇笔记并暂存 git mv old-note-name.md new-note-name.md git add -A # 3. 此时切到终端外、把 Tolaria 窗口切到后台再切回来 # 应用重新获得焦点时会执行 git diff HEAD --name-status --diff-filterR -M # 输出应包含R100\told-note-name.md\tnew-note-name.md # 4. 应用横幅出现 “1 file renamed outside Tolaria. Update wikilinks?” # 点击 “Update wikilinks” 后全库指向 [[old-note-name]] 的 wikilink # 会被批量替换为 [[new-note-name]]toast 报告更新的文件数如果 vault 嵌套在父仓库中vault 不是.git所在目录第 3 步的 diff 会自动加上 pathspec 限定如-- docs/保证只统计 vault 子树内的重命名——这一点由GitWorkspace::resolve与嵌套 vault 测试用例保证。小结ADR-0036 展示了一个典型的“低成本高收益”架构决策面对“外部重命名导致 wikilink 断裂”的问题Tolaria 没有引入文件系统监听这类重武器而是复用 vault 本就依赖的 git用一次git diff --diff-filterR加上两个 Tauri 命令、一个焦点监听钩子和一条非阻塞横幅实现了“检测—确认—批量修复”的完整闭环。其关键工程实践包括-M显式启用 rename 检测、pathspec 限定 vault 子树、非 git 场景静默降级、旧标题/路径 stem 多目标匹配的兼容替换以及把外部修复与应用内重命名收敛到 rename.rs 的同一替换入口。对于任何需要检测 git 仓库中文件移动的桌面/编辑器类应用这套模式都是可以直接借鉴的参考。【免费下载链接】tolariaDesktop app to manage markdown knowledge bases项目地址: https://gitcode.com/GitHub_Trending/to/tolaria创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考