大约五个月前,我们开始了一个项目,该项目是检修和升级旧版PHP-4/5应用程序,然后将其移至PHP-7(以及许多其他功能)。该应用程序包含2700多个文件,并且几乎所有文件都进行了广泛的更改。

同时,旧版应用程序继续为客户提供支持,到目前为止,已进行了约250项更改。我有(并可以制作...)git补丁来表示这些更改。我的直接问题是,大多数人都不是git apply

当然,很容易理解为什么:补丁中表达的“行号”几乎没有用。尽管在大多数情况下都可以找到要查找的源代码,但是它可能已经移动了一段距离。

我目前的想法(基于对大约30个补丁文件的检查)是,在许多有用的情况下,要被补丁的文字源代码仍逐字记录在源文件中,只是不在预期的位置。

尽管我很现实,知道必须手动分析和制作许多补丁,但出于时间和准确性的考虑,我还是希望将其最小化。我希望将要进行此操作的人员(包括我(!)...)能够尽可能地利用自动化工具,因为他们知道他们随后必须按补丁检查工作。我没有幻想我可能能够一次自动地处理所有这些文件,即“Shazam”。

因此,谁在处理类似情况呢?你建议我做什么?一种建议是使用带有patch选项的fuzz命令,请注意,该命令可能会起作用,或者可能导致应用了不正确的补丁程序。

(在任何情况下,我们计划一次做一个补丁:“补丁,git commit,冲洗并重复。”以便我们可以git diff来检查每个更改是否合理。)

要求提供“ war 故事”。谢谢。

最佳答案

git apply提供了几个选项,可用于试探性地或半手动地应用补丁,其大部分描述在 git-apply(1) 手册页上:

  • -C 可以减少为了成功修补必须在块中匹配的上下文行的数量。

  • --recount 将忽略行号。

  • --reject 将留下无法应用于.rej文件的块,就像patch一样。然后,您可以检查这些文件并手动应用更改。

  • --3way 将尝试三向 merge ,假设补丁最初是由git生成的。


  • 我个人使用git apply -C1 --recount成功地将被子补丁转换为git commit。
    或者,您可以简单地使用patch实用程序来应用补丁,而根本不使用git apply命令。默认情况下,patch将模糊地应用块,并保留完全无法在.rej文件中应用的块;如果指定了--merge选项,则失败的块将改为生成冲突标记。

    关于Git:建议在已知来源发生重大变化时应用补丁,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/38039342/

    10-14 02:54