如何解决与“git mergetool”的多个冲突而不必关闭文件之间的编辑器？

Posted 2023-02-19

【中文标题】如何解决与“git mergetool”的多个冲突而不必关闭文件之间的编辑器？

【英文标题】：How resolve multiple conflicts with "git mergetool" without having to close the editor between files?

【发布时间】：2010-10-09 19:23:32

【问题描述】：

我发现 git mergetool 是一种在视觉上合并差异的便捷实用程序，但我这样做的方式似乎真的很不稳定。本质上，当报告冲突时，我的流程如下所示：

执行 git mergetool 在提示符下，按 Enter 启动我的差异工具（Meld 或 FileMerge，具体取决于哪台计算机） 解决冲突 保存更改 关闭差异工具

如果我有多个冲突，请冲洗，重复。是的，这就是我为合并中的每个冲突打开和关闭我的差异查看器一次。由于它是从命令行启动的，因此关闭它是我知道告诉 git mergetool 我已经解决了这个特定冲突并且它可以继续下一个的唯一方法。

当然有更好的方法，但我不知道。丽来帮忙好吗？这个过程似乎非常低效。

【问题讨论】：

您也可以运行git mergetool -y 跳过中间的提示。您可能仍然需要关闭合并工具，但您不必返回终端并为每个新合并点击返回。

如果您正在对一堆文件进行 git 合并，而这就是您所需要担心的，那么您无需担心。

@moeffju 这是加快合并冲突过程的最佳答案。

vimdiff 相关：***.com/questions/1220309/…

【参考方案1】：

乍一看，似乎无法重用外部差异工具会话。

git-mergetool documentation 明确指出：

如果自定义合并工具正确指示合并解析成功及其退出代码，则配置变量mergetool.<tool>.trustExitCode 可以设置为true。 否则，git-mergetool会在自定义工具退出后提示用户指示解析成功。

所以需要退出代码（或diff工具退出后用户的验证），暗示用户先关闭外部diff工具。

这似乎是减少每次合并/变基一次尝试的冲突数量的巨大动力；）（无论使用什么 VCScs 工具）

注意： 其他两个 git 外部 diff 工具设置（“Setting up diff and merge tools for Git on Windows”和“Setting up SourceGear DiffMerge with Git”）在不关闭外部 diff 工具时没有带来更多希望......

【讨论】：

确实如此。 :-) 感谢您的健全性检查。您和其他人使用什么来进行合并？只是在您选择的编辑器中打开文件？

我在 Windows 上使用 WinMerge，但我必须像你一样在每次解决后关闭它。

【参考方案2】：

如果您选择的合并工具支持在现有实例中打开文件，您可以在 git config 中指定命令：

% git config mergetool.whatever_you_want.cmd 'exec /path/to/merge/tool $LOCAL $MERGED $REMOTE'
% git config merge.tool whatever_you_want

git mergetool 然后将执行您的自定义命令，然后提示您文件是否已成功合并（而不是查看退出代码）。

我刚刚为 vimdiff 编写的一个示例：

% git config mergetool.persistent.cmd 'gvim --remote-tab-silent "+set buftype=nowrite" "$PWD/$BASE" && sleep 1; gvim --remote-send ":split $PWD/$REMOTE<CR>:set buftype=nowrite<CR>:vertical diffsplit $PWD/$MERGED<CR>:vertical diffsplit $PWD/$LOCAL<CR>:set buftype=nowrite<CR><C-W>l"'

这很好用，我可以自己开始使用它！

【讨论】：

有趣。我将尝试使用 WinMerge。 +1

我不得不承认，这太棒了。一定要看看我能为 Meld 做些什么。

看起来有一个待处理的补丁和错误票允许以这种方式使用融合：bugzilla.gnome.org/show_bug.cgi?id=453670

这就是我在我们的一个办公室 Windows 系统上设置它的方式，使用超越比较

【参考方案3】：

mergetool 的问题在于它故意使用命令行界面来启动合并会话，然后等待调用的命令返回以确定用户驱动的合并何时完成。

大多数合并工具不提供命令行机制来在已运行的进程中启动合并会话，并提供一种方法来确定解决方案何时完成以及是否成功。

可以想象，一些合并工具可以通过单独的包装器命令和某种 IPC 来提供此功能，但它是非常特定于工具的，并且难以在通用合并工具程序中实现。

【讨论】：

我同意这个分析。 +1

Git 可以根据合并目标是否更新（更改）来判断“合并成功状态”。然后，如果我“保存合并”，则意味着我已成功完成。否则它没有。但是这个用例可能需要两阶段合并。

@phord：对于那些不通过返回值报告状态但在这种情况下无济于事的工具，它确实这样做了，因为仍然没有迹象表明它何时适合 git检查状态，因为工具会话已经开始，并且可以在合并完成后继续。

@Charles：这就是我所说的两阶段合并过程。例如，Step1: "git mergetool -t=mygui" 为所有合并集启动我的 GUI 合并工具。我手动修复冲突并保存它们。第 2 步：“git mergetool -t=finish”检查我的编辑以确认合并成功，并决定如何处理每个文件作为结果（添加/签出）。

@phord：第二步已经存在，因为git add <file> where 有合并冲突意味着“我已经解决了这个合并”。要在接受更改之前获得差异，您已经可以执行 git add -p 。

【参考方案4】：

我一直在寻找这个答案非常非常长的时间。现在我终于得到了这个简单的解决方案（令人惊讶）：

融合。

这将在版本控制视图中打开融合。 这样，您可以解决选项卡中的冲突，并在您单击“标记为已解决”按钮时将其标记为已解决。