Git:在已知源发生重大变化时应用修补程序的建议

Question

大约五个月前，我们开始了一个改造和升级PHP-4/5遗留应用程序的项目，将其迁移到PHP-7 (以及许多其他东西)。该应用程序由2,700多个文件组成，几乎所有的文件都进行了广泛的更改。

同时，遗留应用程序继续支持客户，到目前为止，已经进行了大约250个更改。我有(并且可以) git补丁来表示这些更改。我现在面临的问题是，他们中的大多数人都没有git apply。

当然，这很容易理解为什么:在补丁中表示的“行号”几乎是无用的。虽然在大多数情况下正在寻找的源代码在那里，但它可能被移动了一段距离。

我目前的想法(基于对大约30个补丁文件的检查)是，在有用的情况下--许多情况下，要修补的文字源代码--仍然逐字逐句地出现在源文件中，而不是在预期的位置。

虽然我有足够的现实主义，知道许多这些补丁将需要分析和手工制作，我想尽量减少这一点，无论是为了时间和准确性。我想为将要做这件事的人.包括我.为了能够尽可能多地利用自动化工具，他们知道每个补丁程序都必须检查他们的工作。我没有幻想，我很可能能够同时处理所有这些文件，自动“Shazam”。

因此，有谁处理过类似的情况呢？你建议我做什么？有一个建议是使用带有patch选项的fuzz命令，提醒您，它可能会工作，或者可能会导致应用错误的修补程序。

(我们计划在任何情况下一次做一个补丁：“修补程序、git commit__、漂洗和重复。”这样我们就可以通过git diff来检查每个更改是否正确。)

“战争故事”要求。谢谢。

Answer 1

我也有类似的经历。我们的团队正在开发谷歌的Android代码库，包括不同的芯片组和不同的版本。所谓的常见问题或特性从一个代码库移植或重用到另一个代码库。

如果是从Android M到Android M，就更容易了。但是我们有从Android L到Android M或Android N的问题，一些补丁，通常是数百个，很难直接应用。而git补丁是++- diff，它不够清晰或简单，当我们必须手工应用它们时，我们会发疯。

代码库由400多个git repos组成。因此，我们为每个回购做了一个按日期排序的提交列表。我们为每一次提交做一个前后修补程序。前后补片是并排补片.左边是更改之前的文件，右边是更改后的文件。修补程序文件夹结构类似于<commit>/before，<commit>/after。因此，我们可以很容易地使用像“无法比较”这样的工具，以更友好的方式看到变化。

我们有一个脚本来制作前-后补丁。基本上是这样的：

#!/bin/bash 

#takes one parameter, the commit
commit=$1

#copy the modified files after the change
git checkout -f $commit
git log -1 $commit --name-only --pretty=%h | tail -n +3 | while read line
do
mkdir -p ~/backup/$commit/after/$(dirname $line)
cp -v $line ~/backup/$commit/after/$line
done

#copy the same files before the change
git checkout -f $commit^
git log -1 $commit --name-only --pretty=%h | tail -n +3 | while read line
do
mkdir -p ~/backup/$commit/before/$(dirname $line)
cp -v $line ~/backup/$commit/before/$line
done

然后，差异补丁和前后补丁和列表都被传递给团队成员。如果git diff补丁无法自动应用，我们只需按照前面的修补程序手工应用它。虽然工作量很大，但还是要完成。