资讯详情

MooTool Next Compose 的 Vault Git 能力与 Electron 行为对齐:基于 vaultGitService 对照登记与 GitEngine 源码的深度解析

📅 2026/10/16 2:21:13 | 华诺云谱 👁 阅读
MooTool Next Compose 的 Vault Git 能力与 Electron 行为对齐:基于 vaultGitService 对照登记与 GitEngine 源码的深度解析
桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载MooTool 是一个面向开发者的跨平台工具箱其 Compose 桌面版next-compose正在将 Electron 版的 Vault Git 版本管理能力逐项迁移并对齐。electron-next-vaultGitService-vitest.md 正是这一对账工作的核心登记表逐条列出 ElectronvaultGitService.integration.test.ts覆盖的 Git 行为及其在 Compose 侧GitEngineTest等测试中的对应验证。本文将以这份登记表为骨架结合 GitEngine.kt 的引擎实现与两侧测试源码讲清楚 Vault Git 的初始化、提交、冲突处理、检查点、锁恢复、远端管理与并发安全等机制帮助你理解这套「以测试对齐替代人工比对」的跨实现迁移方法以及每项行为背后的工程细节。一、这份对照登记表是什么登记表的结构非常简单每一行描述一个「caseId」从三个维度记录一个行为点的对齐情况维度说明sourceProduct行为来源产品绝大多数为 MooTool Next ElectronsourceFile源实现/测试所在文件主要是next/src/shared/vaultGitService.integration.test.tsCompose 验证Compose 侧对应的测试类与方法附带 DIFF 文档编号登记表覆盖约 35 个行为点可以归类为以下几组基础生命周期init、commit、history、diff含提交级与工作区级冲突处理pull导致分叉合并冲突、merge/rebase的resolve、abort、continue操作守卫Guardmerge/rebase 期间禁止 commit/pull/push、未解决冲突禁止 continue/commit/pull/push自动化检查点automatic checkpoint首次使用自动初始化、配置远端后自动 push、冲突期跳过检查点健壮性与安全非安全路径拒绝、嵌套 Vault 不被父仓库吸收、index.lock陈旧锁恢复、并发提交序列化、Unicode 路径、提交说明截断 300 字符、远端 URL 校验与空 URL 移除fetch/push 语义fetch --prune、分叉后的 ahead/behind 报告、非快进 push 拒绝UI 呈现VaultGitDialog冲突行「使用本地/远端」Tab 帧、顶栏分支图标与操作钮的 Lucide 对齐。每个 Compose 验证项都挂着一个 DIFF 编号如 DIFF-442DIFF 文档是「行为差异描述 修复方案 验证结果」的完整记录两者配合构成了可追溯的对齐证据链。二、核心引擎GitEngine 的职责划分Compose 侧的对齐验证全部落在GitEngine这个单例对象上源码位于 GitEngine.kt。它的设计值得先看清楚2.1 与 Electron VaultGitService 的镜像关系Electron 侧实现是VaultGitServicenext/electron/main/vaultGitService.ts对外暴露三类接口status()/history()/diff()只读查询action(input)以{ action, path, message, remote, strategy }为参数的统一动作入口内部 switch 到init、configure-remote、commit、fetch、pull、push、discard、abort-merge、resolve-conflict、continue-operationautomaticCheckpoint(message)检查点专用流程。Compose 侧GitEngine则以顶层函数形式提供status、init、commit、history、diff、fileDiffs、setRemote、fetch、pull、push、discard、abortMerge、resolveConflict、continueOperation、automaticCheckpoint等方法。两条实现的命令参数几乎一致——例如status都用git status --porcelainv1 -z --branch --untracked-filesallfetch 都用git fetch --prune originpush 都用git push -u origin HEADpull 都用git pull --no-rebase origin。这保证了「同一行为、同一命令、同一预期」的可比性。2.2 数据模型与关键常量GitEngine定义了清晰的数据结构见 GitEngine.kt 顶部GitStatusavailable、repository、version、branch、remote、ahead、behind、changes、conflicts、merging、operation取值为merge/rebase/noneGitChangepath、originalPath、status、conflictconflict由UU/AA/DD等状态判定GitCommitInfohash、shortHash、author、date、messageGitFileDiffpath、originalPath、status、before、after、previewText/Binary/TooLarge三态GitActionResult统一的successmessage返回。关键常量定义了行为边界普通命令超时TIMEOUT_MS 30_000L远端操作超时REMOTE_TIMEOUT_MS 120_000Ldiff 预览最大512 * 1024字节提交说明截断上限300字符陈旧index.lock判定阈值5分钟。defaultGitignore默认为.DS_Store、.idea/、.vscode/、*.tmp、.migrated-from-db。2.3 执行器进程级隔离与超时控制GitEngine.run是命令执行的统一出口GitEngine.kt它的职责包括设置GIT_TERMINAL_PROMPT0禁止交互式提示设置GIT_OPTIONAL_LOCKS0isolateConfig true时通过GIT_CONFIG_GLOBAL/GIT_CONFIG_SYSTEM指向空设备避免用户全局 Git 配置影响测试结果这也是所有对齐测试统一传isolateConfig true的原因token 非空时写入临时GIT_ASKPASS脚本通过环境变量MOOTOOL_COMPOSE_GIT_TOKEN向脚本传值用两个线程异步排空 stdout/stderr防止管道写满造成死锁超时后destroyForcibly()并返回退出码 124。locked(root)则用ConcurrentHashMapPath, Any配合synchronized保证同一 Vault 目录下所有 Git 操作串行执行——这是并发提交对齐用例的直接实现基础。三、逐项解析登记表中的核心行为点下面按登记表的分组逐项说明行为语义、Electron 测试与 Compose 验证的对应关系以及源码依据。3.1 初始化、提交与历史init / commit / diff / history登记表第一行init-commit-diff-history对齐的是 Electron「initializes, reports changes, commits, shows history, and builds a diff」这条完整链路。两端测试都覆盖了以下断言未初始化时status().repository falseinit后写入默认.gitignore必须包含.DS_Store工作区出现.DS_Store也不进入变更列表Compose 对应GitEngineTest.initWritesGitignoreAndIgnoresDsStore未跟踪文件在status.changes中以??呈现commit后history首条即为本次提交author 非空diff({ commit })返回该提交的文件级前后内容diff({ path })返回工作区相对 HEAD 的前后内容。Compose 侧对应的mirrorsElectronVaultGitInitCommitDiffHistoryGitEngineTest.kt把这条链路完整重演了一遍提交sample.json两版内容验证fileDiffs的before/after分别等于旧值与新值并且新文件的before为空、preview为Text。实现层面GitEngine.commit内部会先把提交说明trim().take(300)截断空说明返回失败merge/rebase 进行中直接拒绝无变更返回No changes to commit随后执行git add --all与git commit -m。提交命令通过identityArgs携带-c user.name、-c user.email、-c commit.gpgsignfalse与 Electron 的ensureIdentity()逻辑对应。3.2 提交说明 300 字符截断commit-message-300对应 Electron 的说明截断行为。Compose 的truncatesCommitMessageToThreeHundredCharacters直接传入 320 个m提交再断言history返回的 message 恰好为 300 字符。实现依据是commitLocked中的message.trim().take(300)GitEngine.kt。3.3 冲突处理pull、merge、rebase 的完整闭环登记表围绕冲突操作列出多条pull-merge-conflict-resolve、rebase-continue、merge-abort/continue。分叉 pull 产生合并冲突pullLeavesMergeConflictWhenHistoriesDiverge构造 bare 仓库、upstream 与 local 三方环境upstream 提交Base后 pushlocal clone随后两边各自修改同一文件并提交此时GitEngine.pull必然失败status显示operation merge、merging true、conflicts 1。接下来用resolveConflict(root, path, theirs)解决冲突status.conflicts归零continueOperation成功最终operation none。Electron 侧对应的「resolves and aborts real merge conflicts」测试路径完全一致vaultGitService.integration.test.ts。merge 的 abort 与 continueresolvesAndAbortsMergeConflicts验证解决冲突后可abortMerge干净退出continuesMergeAfterConflictResolved验证解决后continueOperation能正常收尾。实现上abortMerge先试git merge --abort失败再试git rebase --abortGitEngine.ktcontinueOperation在operation rebase时执行rebase --continue附带-c core.editortrue否则执行commit --no-edit但冲突未清一律拒绝GitEngine.kt。rebase 的 continuecontinuesRebaseAfterConflictResolved复现了 rebase 冲突→resolveConflict(theirs)→continueOperation的流程验证operation从rebase回到none。这与 Electron 的「detects and continues a rebase after conflicts are resolved」用例逐条对应。resolve-conflict 的两种策略resolveConflict只接受ours/theirs两个策略内部执行git checkout --ours/--theirs -- path后git add对未处于冲突状态的文件返回Git path is not conflictedGitEngine.kt。3.4 操作守卫冲突期禁止 commit / pull / push / continue登记表中出现了一组形态相同的守卫行为这是「操作顺序正确性」的对齐重点caseId行为Compose 验证类commit-during-mergemerge 中禁止 commitrejectsCommitWhileMergeInProgresscommit-unresolved-conflicts未解决冲突禁止 commitGitCommitGuardTest.commitBlockedWhileMergeConflictsRemainpull-during-mergemerge 中禁止 pullGitPullGuardTest.mergeInProgressRejectedBeforeMissingRemoteMessagepull-unresolved-conflicts未解决冲突禁止 pullGitPullGuardTest.pullBlockedWhileMergeConflictsRemaincontinue-unresolved-conflicts冲突未解决禁止 continueGitContinueGuardTest/GitRebaseGuardTestpull-during-rebaserebase 中禁止 pullGitRebaseGuardTest.pullBlockedWhileRebaseInProgresscommit-during-rebase-conflictsrebase 冲突未清禁止 commitGitRebaseGuardTest.commitBlockedWhileRebaseConflictsRemainpush-unresolved-conflicts冲突未清禁止 pushGitPushGuardTest.pushBlockedWhileMergeConflictsRemainabort-rebase-unresolvedrebase 冲突态允许 abortGitRebaseGuardTest.abortEndsRebaseWithUnresolvedConflicts从GitEngine.pull的实现可以看到守卫顺序GitEngine.kt先检查repository再检查merging返回Finish or abort the current merge/rebase before pulling随后检查conflicts 0返回Resolve all conflicts before pulling最后才检查 remote。GitPullGuardTest.mergeInProgressRejectedBeforeMissingRemoteMessage专门锁定「merge 进行中时错误提示必须命中 merge 语义且不能出现 remote 字样」即守卫优先级高于远端校验。push的守卫链与之类似GitEngine.ktmerge/rebase 进行中或存在冲突都直接拒绝。这些 guard 测试的 fixture 模式相同构造base/other/base-branch三方修改同一文件git merge other必失败制造冲突态然后调用目标动作断言失败文案。3.5 自动检查点automatic checkpointautomatic-checkpoint-init/push与automatic-checkpoint-conflict-skip两条对应 ElectronautomaticCheckpoint()与 ComposeautomaticCheckpoint()GitEngine.kt的完整语义首次使用自动初始化目录还不是仓库时automaticCheckpoint内部调用init并以「Initial MooTool Vault setup」作为首个提交说明。对应用例automaticCheckpointInitializesRepositoryOnFirstUse与 Electron「initializes a new Vault when creating its first automatic checkpoint」配置远端后自动 push有未提交变更或ahead 0且remote已配置时检查点提交完成后自动git push -u origin HEAD。对应用例automaticCheckpointPushesWhenRemoteConfigured会去 bare 仓库执行git log --all断言提交确实到达远端且status().ahead 0冲突期跳过merging || conflicts 0时返回「Merge/rebase in progress; checkpoint skipped」并保持 HEAD 不变。resolvesAndAbortsMergeConflicts中断言冲突期间的检查点调用后 history 首个 hash 与冲突前一致。这个流程保证了「随手记/JSON 笔记自动保存到 Git」不会在合并中途制造脏提交——这正是登记表标注对齐 ElectronautomaticCheckpoint的核心价值。3.6 安全与路径规则rejects-unsafe-pathsfileDiffsMatchesElectronPathRules验证../outside抛出IllegalArgumentException(Invalid Git path)而valid..name.json合法但无变更返回空列表。实现依据是normalizeGitPathGitEngine.kt拒绝绝对路径、含\u0000、长度超 512 的路径并拒绝任意一段为./../空串的相对路径parent-repo-not-adoptedrejectsParentRepositoryUntilVaultRootIsInitialized构造「父目录已 Git init、子目录为 Vault」的嵌套场景断言status(vault)先报告repository falseinit(vault)之后才成为独立仓库且父仓库的git status能继续看到outside-unrelated.txt——即嵌套 Vault 不会被父仓库的git add --all吞并。这一点由status()中rev-parse --show-toplevel与root.toRealPath()的比对逻辑保障GitEngine.ktunicode-pathsunicodePathsWorkForStatusDiffDiscardAndRename用中文文件名验证 status/diff/discard/rename 全链路重命名后status.changes需同时给出path与originalPath。3.7 index.lock 恢复与并发提交这是GitEngine.run最精细的一段逻辑GitEngine.kt对应登记表三条用例stale-index-lock命令因unable to create ... index.lock ... file exists失败后先sleep(250ms)重试一次仍失败则走quarantineStaleIndexLock。隔离流程为锁文件存在且最后修改时间距今超过 5 分钟STALE_INDEX_LOCK_MS→ 用lsof -t确认无进程占用 → 再等100ms确认 mtime 稳定 → 把锁文件改名为index.lock.mootool-stale-时间戳-pid→ 重试命令 →finally删除隔离文件。对应用例repairsStaleIndexLockAndRetriesCommit在锁文件 mtime 设为 10 分钟前的前提下断言提交成功、锁文件消失、.git下没有残留index.lock.mootool-stale-*recent-index-lock锁文件刚创建不足 5 分钟时不做隔离commit返回失败且文案包含index.lock。对应用例recentIndexLockBlocksCommitheld-index-lock锁文件虽陈旧但被本进程以文件句柄占用时lsof -t检测到占用不做隔离提交保持失败。对应用例doesNotQuarantineIndexLockHeldOpenByThisProcess该用例依赖平台lsofmacOS 为/usr/sbin/lsofLinux 为lsofElectron 侧同样用skipIf(!lockInspectorAvailable)做条件跳过。并发提交序列化serializesConcurrentCommitsForSameVaultRoot用双线程同时发起两条不同 message 的提交断言两个结果都成功但git log --pretty%s -- concurrent.txt只能看到一条 message——说明后到的提交看到的是已经干净的工作区不会产生叠加提交。Electron 侧同名用例使用「两个独立VaultGitService实例并行Promise.all」验证的是repositoryOperationQueues按目录的队列化Compose 侧locks的synchronized达到同一效果。3.8 fetch 与 push 的远端语义登记表后半段集中对齐远端操作push-non-ffpushFailsWhenRemoteIsAheadWithoutPull让两个 clone 先后 push 到同一 bare 仓库第二个 push 必须失败且文案匹配rejected/non-fast-forward/fetch first之一。这对应 Electron 侧「rejects non-fast-forward push」语义fetch-prune-behindfetchUpdatesBehindWithoutPullingWorkingTree验证git fetch --prune origin只更新远端追踪引用status.behind从 0 变为 ≥1但工作区文件v2.txt依然不存在随后pull才真正落盘。对应 Electron「fetch updates behind without pulling the working tree」fetch-prune-stale-reffetchPruneRemovesStaleRemoteTrackingBranch先让客户端 fetch 到origin/feature远端删除该分支后再次 fetchgit branch -r不再出现origin/feature——验证 prune 清理陈旧追踪分支fetch-diverged-ahead-behindfetchReportsAheadAndBehindWhenBranchesDiverge验证分叉后 fetch 能同时更新 ahead 与 behind且不触碰工作区fetch 未配置远端fetchFailsWhenRemoteIsNotConfigured断言失败文案包含remoteconfigure-remote-removeconfigureRemoteRemoveClearsOriginFromStatus与configureRemoteRemoveWhenAlreadyRemovedIsIdempotent验证空 URL 删除origin的幂等语义首次删除返回成功且status.remote 二次删除返回「Remote is already removed」。Electron 侧对应「removes a configured remote when an empty URL is saved」远端 URL 校验rejectsUnsafeGitRemotes验证javascript:alert(1)、/etc/passwd这类 URL 被拒绝normalizeGitRemote只放行https?://、ssh://、git://、git、file://前缀见 GitEngine.kt合法file://URL 可配置空字符串可移除。3.9 UI 呈现层的对齐登记表末行与底注说明 UI 层也有明确的对照物git-ui-abort-copymerge/rebase 中止与确认文案、continue/counts/resolve/pull 的显隐与 busy 状态由GitOperationPresentationTest锁定参见 DIFF-520merge-conflict-ui-hint未解决冲突的说明文案与变更行冲突em高亮由GitMergeConflictPresentationTest与VaultGitDialog锁定底注补充了两条 UI 对照VaultGitDialog冲突行「使用本地/远端」的 Compose Tab 帧编号 142见 DIFF-437以及顶栏分支图标与操作钮的 Lucide 图标对齐见 DIFF-540。四、跨实现对齐的验证方法论这份登记表本身就是一个值得借鉴的工程实践用一张 caseId 表把两个实现的行为一一钉死再用同名/同语义测试双向锁定。要点有三统一 fixture 模式冲突类测试几乎都遵循「base 提交 →checkout -b other修改提交 → 切回 base 修改提交 →merge/rebase制造冲突」的固定剧本两侧代码逐行对应降低了环境差异带来的噪声双保险验证引擎层断言GitEngineTest/GitEngine*GuardTest与呈现层断言Git*PresentationTest分离行为正确性与 UI 文案/显隐分开验证可追溯的差异记录每个行为点挂在 DIFF 文档上如 DIFF-443、DIFF-475DIFF 文档写明背景、行为差异、修复方案与./gradlew :composeApp:desktopTest --offline的通过统计形成从需求到测试再到验证的完整闭环。五、如何在当前仓库中验证这些行为所有 Compose 侧测试都位于 desktopTest 目录下主要文件包括GitEngineTest.kt生命周期、冲突、fetch/push、锁恢复、并发、Unicode、路径规则的引擎级测试GitCommitGuardTest.kt/GitPullGuardTest.kt/GitPushGuardTest.kt/GitRebaseGuardTest.kt各类冲突态守卫测试GitMergeConflictPresentationTest.kt/GitOperationPresentationTest.ktUI 呈现测试。Electron 侧的源测试是 next/src/shared/vaultGitService.integration.test.ts实现是 next/electron/main/vaultGitService.ts。运行验证的方式# 在 next-compose 目录下运行 Compose 桌面测试需要本机安装 git CLI ./gradlew :composeApp:desktopTest --offline需要注意的适用前提冲突/锁/远端相关用例通过assumeGit()或Assume.assumeTrue在未安装 git 时自动跳过held-index-lock用例额外要求lsof可用Electron 侧同样按平台条件跳过不属于失败。六、小结Vault Git 是 MooTool 把「随手记、JSON 笔记等本地数据放进一个可版本化的目录」的关键基础设施。本文基于 electron-next-vaultGitService-vitest.md 这份对照登记表梳理了从init/commit/diff基础链路到 merge/rebase 冲突闭环、操作守卫、自动检查点、index.lock恢复、并发序列化、fetch/push 远端语义再到 UI 呈现的完整行为清单并用 GitEngine.kt 的实现逐项印证。对正在做跨实现功能迁移的团队来说这套「行为登记表 同名测试对 DIFF 追溯」的方法本身就比任何一条具体行为都更有长期价值。赞分享桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载相关推荐MooTool Vault Git 面板文案对齐实战Compose git.* 与 Electron json.git.* 全量对照解析MooTool Vault Git 面板文案对齐实战Compose git. 与 Electron json.git. 全量对照解析 导读 在 MooTool桌面应用开发工具MooTool Compose 版 Vault Git 角标即时刷新基于 onGitStatusChanged 回调对齐 Electron 行为的实现解析MooTool Compose 版 Vault Git 角标即时刷新基于 onGitStatusChanged 回调对齐 Electron 行为的实现解析 导桌面应用开发工具MooTool Vault Git 自动检查点DIFF-412 活动记录与 Compose/Electron 行为对齐实践MooTool Vault Git 自动检查点DIFF 412 活动记录与 Compose/Electron 行为对齐实践 本文基于 next compose桌面应用开发工具上一篇DeepTutor v1.3.5 可靠性专项解析本地启动、RAG 检索与本地 Embedding 兼容性改进下一篇如何用Spek音频频谱分析器快速检测音频质量免费开源工具终极指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。

↑