图形补丁实用程序
我有一个内核补丁，其内核版本与我要修补的内核版本略有不同。不用说，补丁部分失败了。我当然可以手动修复它，但我想知道也许有一个图形补丁实用程序可以用来解决冲突。
I have a kernel patch for a slightly different kernel version then the one I'm trying to patch. Needless to say, the patch partially fails. I can certainly fix it manually, but I was wondering maybe there is a graphical patch utility that can be used to resolve the conflicts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有很多图形修补实用程序，请尝试
meld、diffuse、kdiff3或dirdiff，它们应该为您打包分配。另一个有用的工具是 wiggle，它“更努力地”解决冲突，并将 rej 文件从 patch 转换为 CVS 样式的内联冲突，并使用 >>> 。标记。
我倾向于将它与底层修订系统一起使用，因此如果更改错误，我很乐意恢复其更改，因此我使用：
wiggle -v --replace;
这表示要进行适当的转换，有时它会做正确的事情，其他时候你最终会得到>>>标记并可以手动编辑，但这比手动使用 rej 文件更容易。如果它确实做得不好，我会使用我的版本控制系统（git）恢复到原来的状态。
There are many graphical patching utilities, try
meld,diffuse,kdiff3ordirdiff, they should be packaged for your distribution.Another useful tool is
wiggle, which "tries harder" to resolve conflicts, and will turn a rej file from patch into a CVS-style inline conflict with >>> markers.I tend to use it with an underlying revision system, so I'm happy to revert its changes if they're wrong, as such I use:
wiggle -v --replace <file> <file.rej>Which says to do the transformation in place, sometimes it will just do the right thing, other times you end up with >>> markers and can edit by hand, but it's easier than using a rej file by hand. If it really does a bad job I use my revision control system (git) to revert back to the original.
我不知道图形补丁实用程序，但我可能会做的是获取旧内核版本中的文件，应用补丁来获取修补的旧文件（保留旧文件） ，获取新内核版本中的文件，然后使用三向合并工具，例如 GNU Meld< /a>.
这个过程有点耗时，但我发现它对于解决 Subversion 冲突非常有帮助（与您想要完成的非常相似）。而且，它允许您快速确定两个内核版本中的文件有什么不同、发生了什么变化以及您可能需要对补丁行进行的各种更改，以便使它们与新文件兼容。
I don't know about a graphical patch utility, but what I would probably do is obtain the file(s) in the old kernel version, apply the patch to obtain patched old file(s) (keeping the old file(s)), obtain the file(s) in the new kernel version, and then use a 3-way merge tool such as GNU Meld.
This procedure is a little time consuming, but I have found it extremely helpful in resolving Subversion conflicts (very similar to what you are trying to accomplish). And, it allows you to quickly ascertain how different the file(s) in the two kernel versions are, what has changed, and various changes that you will likely need to make to the patch lines in order to make them compatible with the new file(s).
是的，我在尝试将 Firefox Light v27 补丁应用于 Firefox v28 beta 4 时遇到了类似的情况。Mozilla 团队重命名了一些内容，所以它不是直接插入的。我希望这样做，以便我可以为 Linux 编译它。我最终在一个文本编辑器中打开补丁，在另一个文本编辑器中打开代码。
它是 Mousepad，但它可以是任何简单的文本编辑器，gEdit、Leafpad、Geany...然后手动完成所有 mods，并排，从一个窗口到下一个窗口，但速度太慢了方式。 “查找”有助于跳转到正确的编辑位置。
我还应该提到，如果您将正在使用的补丁片段粘贴到空窗口中，您可以查找并替换 + 符号，然后将其替换为任何内容，因此它将其剥离为可用的代码...对于添加的大块代码来说更容易，而不是在向上箭头和删除键上摆弄手指。
Yeah, I ran into a similar situation while trying to apply Firefox Light v27 patches to Firefox v28 beta 4. The Mozilla team renamed some things, so it's not a direct drop in. I was hoping to do this so I could compile it for Linux. I ended up opening the patch in one text editor, and the code in another.
It was Mousepad, but it coulda been any simple text editor for that matter, gEdit, Leafpad, Geany... Then did all the mods by hand, side-by-side, from one window to the next, but it's so slow that way. "Find" was helpful in jumping to the right edit locations.
I should also mention that if you paste the piece of the patch you're using into an empty window, you can Find-and-Replace the + symbol then replace it with nothing, so it strips it down to usable code... Which is easier for large blocks of added code, instead of twiddling your fingers on the up-arrow and delete keys.