桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载导读本文以 MooTool Next Composenext-compose子工程的 DIFF-619 变更切片为线索解析桌面端 Git 保险库面板在 merge/rebase 冲突期间的远程操作行为fetch 只要配置了 remote 即可用而 pull 在 merge/rebase 进行中强制禁用。文章从展示层判定函数GitVaultRemotePresentation/GitOperationPresentation、引擎层守卫GitEngine.pull/fetch到 UI 接线VaultGitDialog逐层还原实现并给出GitMergeProductEvidenceFlowTest、GitRebaseProductEvidenceFlowTest等测试证据流以及证据帧214的生成方式读者可据此复现验证命令并理解整套冲突期操作矩阵。变更背景DIFF-619 在整个冲突期证据链中的位置MooTool Next Compose 的 Git 保险库JSON Vault面板迭代采用「DIFF 变更切片」方式推进每个切片锁定一类冲突期操作行为并配套独立证据帧。DIFF-619 的基线是 DIFF-618 变更切片工作区后者已锁定冲突未清时commit禁用帧 212/213而 619 在相同冲突态下继续细分远程操作DIFF 切片锁定行为关键证据帧DIFF-609merge §B push/pull 禁用204-compose-git-merge-push-disabled-tab-focus.pngDIFF-616rebase §C push/pull 禁用211-compose-git-rebase-push-pull-disabled-tab-focus.pngDIFF-617rebase resolve 提示 完成后 pull 恢复走查 hintDIFF-618merge/rebase 冲突期提交禁用212/213DIFF-619冲突期 fetch 仍可用、pull 禁用214DIFF-619 明确不重复618 的提交禁用链也不重复211 的 push/pull 禁用链聚焦于fetch 例外可用这一独特行为并强调仅要求 remote这一前置条件。核心行为规则fetch 只依赖 remotepull 依赖冲突状态DIFF-619 的范围描述如下原文语义A03对齐 ElectronVaultGitDialogfetch在 merge/rebase 进行中仍可用仅要求 remotepull在merging时禁用。fetch在 merge/rebase 冲突期间保持可用唯一前提是仓库配置了 remotestatus.remote非空pull只要status.merging true即禁用即使 remote 已配置。这与用户的直觉相反许多人认为冲突期间一切远程操作都应暂停其设计意图在于fetch 只从远端下载引用、不会触碰工作区与暂存区因此即使冲突未解决也不会破坏冲突现场反而可以帮助开发者查看上游最新状态而 pull 会尝试合并远端变更在冲突未清时继续 pull 只会叠加新的冲突故必须在 UI 与引擎两层同时拦截。展示层实现判定函数与 busy 门控冲突期操作是否可用的判定集中在commonMain的两个 presentation 对象中分别承担文案与可用性职责。GitOperationPresentation基础判定GitOperationPresentation.kt 提供基础判定fun pullEnabled(remotePresent: Boolean, merging: Boolean): Boolean remotePresent !merging fun pushEnabled(remotePresent: Boolean, merging: Boolean): Boolean remotePresent !merging fun fetchEnabled(remotePresent: Boolean): Boolean remotePresentpullEnabled/pushEnabled要求remote 存在且非 mergingmerge/rebase 进行中一律禁用fetchEnabled只要求 remote 存在不关心 merging 状态——这就是冲突期 fetch 可用的判定源头。GitVaultRemotePresentationbusy 门控 冲突数约束GitVaultRemotePresentation.kt 在基础判定之上叠加busy操作进行中与conflicts未解决冲突数fun fetchActionEnabled(persistedRemote: String, busy: Boolean): Boolean !busy fetchEnabled(persistedRemote) fun pullActionEnabled( persistedRemote: String, merging: Boolean, busy: Boolean, conflicts: Int 0, ): Boolean !busy pullEnabled(persistedRemote, merging, conflicts)参数含义与取值约束参数类型说明persistedRemoteString已持久化的originremote URL空白即视为无 remotemergingBoolean由GitStatus.merging传入表示 merge/rebase 进行中busyBoolean面板忙碌态任一 Git 操作执行期间为true此时所有按钮禁用conflictsInt未解决冲突计数 0时 pull/push 禁用fetch 不受影响单元测试 GitVaultRemotePresentationTest.kt 对此有直接断言fetchActionEnabled(remote, busy false)为truefetchActionEnabled(remote, busy true)为falsebusy 门控fetchActionEnabled(, busy false)为false无 remote 禁用pullActionEnabled(remote, merging true, busy false)为false冲突期 pull 禁用。引擎层守卫GitEngine.pull 与 fetch 的双重防线UI 层禁用只是第一道防线真正的硬性约束在GitEngine引擎层。即使绕过 UI 直接调用引擎冲突期 pull 依然会被拒绝而 fetch 放行。pullmerge/rebase 与冲突双重拦截GitEngine.kt 中pull的执行顺序刻意将状态守卫放在 remote 校验之前fun pull(root: Path, isolateConfig: Boolean false, token: String ): GitActionResult locked(root) { val current status(root, isolateConfig) if (!current.repository) returnlocked GitActionResult(false, Git repository is not initialized) if (current.merging) returnlocked GitActionResult(false, Finish or abort the current merge/rebase before pulling) if (current.conflicts 0) { returnlocked GitActionResult(false, Resolve all conflicts before pulling) } if (current.remote.isBlank()) returnlocked GitActionResult(false, No origin remote is configured) val result run(listOf(pull, --no-rebase, origin), root, isolateConfig, token, REMOTE_TIMEOUT_MS) ... }current.merging时立即返回失败错误信息为 Finish or abort the current merge/rebase before pullingcurrent.conflicts 0时返回 Resolve all conflicts before pullingmerge/rebase 校验先于 remote 校验这一点由 GitPullGuardTest.kt 专门锁定测试mergeInProgressRejectedBeforeMissingRemoteMessage断言 merge 进行中时 pull 的失败信息包含 merge 而不包含 remote证明守卫优先级正确。fetch仅要求 remote而fetch的实现GitEngine.kt#L238-L240只做一件事fun fetch(root: Path, isolateConfig: Boolean false, token: String ): GitActionResult locked(root) { requireRemote(root, isolateConfig) { run(listOf(fetch, --prune, origin), root, isolateConfig, token, REMOTE_TIMEOUT_MS) } }requireRemote同文件 L500-L507仅校验仓库已初始化 origin remote 已配置随后执行git fetch --prune origin完全没有 merging / conflicts 守卫——这与展示层fetchEnabled只依赖 remote 的规则完全对齐构成UI 判定 引擎行为的一致性。status如何识别 merge/rebase 进行中GitStatus.merging与operation字段由 GitEngine.status 判定val merge run(listOf(rev-parse, -q, --verify, MERGE_HEAD), root, isolateConfig) val rebaseMerge gitPathExists(root, rebase-merge, isolateConfig) val rebaseApply gitPathExists(root, rebase-apply, isolateConfig) val operation when { rebaseMerge || rebaseApply - rebase merge.exitCode 0 - merge else - none }即存在MERGE_HEAD判定为 merge存在.git/rebase-merge或.git/rebase-apply目录判定为 rebase其余为nonemerging operation ! none。冲突数则由status --porcelainv1 -z --branch --untracked-filesall解析中U/AA/DD标记统计。UI 接线VaultGitDialog 工具栏按钮的 enabled 表达式VaultGitDialog.kt 中工具栏三个远程按钮直接引用上述判定函数// fetch —— 冲突期仍可用仅要求 remote MooButton( container.t(git.fetch), p5Toolbar true, enabled GitVaultRemotePresentation.fetchActionEnabled(status.remote, busy), onClick { runAction { GitEngine.fetch(root, token token()) } }, leading { GitPanelIcon(GitPanelIconKind.CloudDownload, colors.textBody) }, ) // pull —— merging 时禁用 MooButton( container.t(git.pull), p5Toolbar true, enabled GitVaultRemotePresentation.pullActionEnabled( status.remote, status.merging, busy, conflicts status.conflicts, ), onClick { runAction(workingTree GitVaultFlushAction.Pull) { GitEngine.pull(root, token token()) } }, ) // push —— 同样 merging/conflicts 时禁用 MooButton( container.t(git.push), p5Toolbar true, enabled GitVaultRemotePresentation.pushActionEnabled( status.remote, status.merging, busy, conflicts status.conflicts, ), ... )同面板内commit按钮L664-L674则使用GitOperationPresentation.commitActionEnabled(busy, merging, conflicts, hasChanges, messageTrimmed)!merging conflicts 0 hasChanges message.trim()四条件同时满足才可用——这正是 DIFF-618 锁定的提交禁用链与 619 的 fetch 可用形成鲜明对照同一冲突态下commit/pull/push 三类操作按不同规则分别放行或拦截而 fetch 是唯一保持可用的远程操作。此外工具栏还依据GitOperationPresentation.inProgressMessageKey(status.operation, status.merging)渲染状态胶囊merge 显示git.operationMergerebase 显示git.operationRebase冲突数在showChangeCounts为真时以 danger 色显示与按钮状态一起构成冲突期的完整视觉反馈。测试证据流从制造冲突到 fetch 真实成功DIFF-619 指定的证据流测试是GitMergeProductEvidenceFlowTest与GitRebaseProductEvidenceFlowTest两者在冲突态下断言fetchActionEnabled true并调用真实GitEngine.fetch验证成功。merge 证据流GitMergeProductEvidenceFlowTestGitMergeProductEvidenceFlowTest.kt 的核心流程创建 bare 远端 upstream local 三个临时仓库upstream提交{side:base}后 push 到 barelocalclone 后upstream提交{side:remote}并 pushlocal提交{side:local}制造分叉GitEngine.pull(local)触发冲突GitEngine.status断言operation merge、merging true、conflicts 1冲突态断言矩阵pushActionEnabled→falsepullActionEnabled→falsecommitActionEnabled→falsefetchActionEnabled(status.remote, busy false)→true随后val fetched GitEngine.fetch(local, isolateConfig true)断言fetched.success——真实引擎调用验证冲突期 fetch 成功resolveConflict(local, conflict.json, theirs)清零冲突 →mergeContinueActionEnabled恢复 →continueOperation完成 merge → 断言operation none且 push/pull 重新可用。rebase 证据流GitRebaseProductEvidenceFlowTestGitRebaseProductEvidenceFlowTest.kt 流程与 merge 版基本对称差异在于冲突制造改用git pull origin branch --rebase失败即进入 rebase 冲突态GitEngine.status断言operation rebase冲突态下同样断言fetchActionEnabled true并真实调用GitEngine.fetch(local, isolateConfig true)验证成功resolve 时方向相反rebase 冲突中ours为 upstreamremote、theirs为 replay 的本地提交故使用ours源码注释明确说明对齐git checkout --ourscontinueOperation在 rebase 分支走git rebase --continue引擎实现见 GitEngine.kt#L426-L436merge 分支走git commit --no-edit。两个测试文件均通过GitIdentity(MooTool Evidence, mootool-evidencelocal)隔离身份、isolateConfig true隔离全局配置执行并在finally中删除临时目录。冲突态断言汇总断言点merge 冲突态rebase 冲突态merge/rebase 完成后fetchActionEnabledtruetruetrue不恢复概念全程可用GitEngine.fetch真实调用successsuccess—pullActionEnabledfalsefalsetrue恢复pushActionEnabledfalsefalsetrue恢复commitActionEnabledfalsefalse—mergeContinueActionEnabledfalsefalsetrue冲突清零后证据帧 214UI 捕获测试生成fetch 可用 / pull 禁用帧除了引擎层证据流DIFF-619 还通过 GitVaultFetchDuringConflictCaptureTest.kt 生成 UI 证据帧输出文件为next-compose/docs/evidence/2026-09-15-inspector-screencapture/windows/214-compose-git-rebase-fetch-enabled-pull-disabled-tab-focus.png该测试使用 Compose UI 测试框架runDesktopComposeUiTest(width 560, height 120)渲染与VaultGitDialog顶栏一致的控件组合MooStatusPill(zh.t(git.operationRebase), kind MooStatusKind.Error) // 变基进行中胶囊错误色 MooButton(zh.t(git.fetch), p5Toolbar true, enabled GitVaultRemotePresentation.fetchActionEnabled(remote, busy false)) // fetch 启用 MooButton(zh.t(git.pull), p5Toolbar true, enabled GitVaultRemotePresentation.pullActionEnabled( persistedRemote remote, merging true, busy false)) // pull 禁用随后onRoot().captureToImage().toAwtImage()捕获整根节点并写入指定路径并断言 PNG 文件大小 500 字节保证帧非空。测试文件名与 DIFF 文档中的帧编号214一一对应与211push/pull 禁用、212/213提交禁用共同构成冲突期操作矩阵的完整证据帧序列。配合证据帧的脚本侧提示见 product-evidence-common.sh 的mootool_evidence_print_git_rebase_product_hint其中明确登记rebase 进行中 push/pull 应禁用、fetch 仍可用GitVaultRemotePresentationCompose 帧 211/214同时说明冲突未清时「提交」应禁用帧 213 /commitEnabled产品走查产品主窗 §C仍需手工截图登记至docs/evidence/2026-09-17-vault-conflict-product-window/results.md。证据仓库制备脚本如何手动复现 rebase 冲突态如需手动走查产品窗的 rebase 冲突态可运行证据制备脚本next-compose/scripts/prepare-git-rebase-conflict-evidence.sh脚本核心步骤与GitRebaseProductEvidenceFlowTest同构在隔离 JSON Vault 数据目录下创建 bare 远端_evidence_git_rebase_remote.git与 upstream 克隆_evidence_git_rebase_upstream_clonegit init -b main初始化 Vault 仓库提交conflict.json内容{side:base}并 push 建立originupstream 提交{side:remote}并 push本地提交{side:local}后执行git pull origin main --rebase制造变基冲突通过mootool_evidence_assert_git_rebase_conflict断言验证存在.git/rebase-merge或.git/rebase-apply目录且git diff --name-only --diff-filterU非空输出产品走查提示自动选中conflict.json、ours/theirs 解决、continue 完成变基。脚本通过GIT_CONFIG_GLOBAL/dev/null、GIT_CONFIG_SYSTEM/dev/null及isolateConfig语义隔离全局 git 配置确保复现结果确定性。merge 冲突态对应脚本为prepare-git-merge-conflict-evidence.sh断言MERGE_HEAD存在。本地验证方式DIFF-619 指定的验证命令JDK 21 环境离线模式./gradlew :composeApp:desktopTest --offline --no-daemon该命令会执行desktopTest全部测试覆盖上述GitMergeProductEvidenceFlowTest、GitRebaseProductEvidenceFlowTest、GitVaultFetchDuringConflictCaptureTest及GitVaultRemotePresentationTest、GitPullGuardTest等守卫测试。若目标环境已安装 git CLIassumeGit()前置条件满足后证据流测试会真实走完整流程含GitEngine.fetch真实执行未安装 git 时相关测试自动跳过Assume。总结冲突期操作矩阵的完整设计DIFF-619 并非孤立的一条规则而是 MooTool Next Compose Git 保险库冲突期操作矩阵的一部分从GitOperationPresentation基础判定 →GitVaultRemotePresentationbusy/conflicts 门控 →GitEngine引擎守卫 →VaultGitDialogUI 接线四层规则保持严格一致fetch只要求 remote冲突期可用DIFF-619 锁定pullremote !mergingconflicts 0冲突期禁用DIFF-609/616/619 锁定pushremote !mergingconflicts 0冲突期禁用DIFF-609/616 锁定commit!mergingconflicts 0 有变更 消息非空冲突期禁用DIFF-618 锁定resolve / continue / abort随冲突数动态启用冲突清零后 continue 恢复。每条规则都配备引擎层真实执行的证据流测试 Compose UI 捕获证据帧使冲突期 fetch 可用、pull 禁用这一看似反直觉的设计具备了可复现、可审计的完整证据链。赞分享桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载相关推荐opensre 交互式 Shell 动作工具实现指南tools/interactive_shell 包架构、子进程解耦与依赖边界opensre 交互式 Shell 动作工具实现指南 tools/interactive_shell 包架构、子进程解耦与依赖边界 opensre开源 AI桌面应用开发工具Kornia 端到端应用实战指南用 PyTorch 组合图像增强、匹配、拼接与视觉提示Kornia 端到端应用实战指南用 PyTorch 组合图像增强、匹配、拼接与视觉提示 本文是 Kornia 官方文档 applications https:桌面应用开发工具MooTool Next Compose 的 Git Rebase 冲突解析与 Continue 集成从 resolveConflict 到「继续合并 / Rebase」的完整链路MooTool Next Compose 的 Git Rebase 冲突解析与 Continue 集成从 resolveConflict 到「继续合并 / R桌面应用开发工具上一篇零训练AI换脸神器roop-unleashed完整入门指南下一篇5分钟零基础上手roop-unleashed AI换脸工具终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考