问题标签 [git-apply]

我有一个 3 个月大的提交，假设提交 A 涉及 3 个文件在过去的 3 个月中，有更多的提交进入，其中一些在提交 A 的更改下方添加了新代码

我想从 3 个文件中的 1 个中的提交 A 中删除（而不是还原）更改。

删除为空行而不是代码

我试过

git show < A的提交哈希> file_path | git 申请 -R -3

这将删除额外的代码（这超出了提交 A 的范围：如果有兴趣，请参见下面的详细信息）

我能想到的一种方法是在文件上使用 git blame，只要哈希匹配，删除行，但似乎是非常迭代的过程和耗时。

任何指针都会有所帮助..

提前致谢

从文件中删除超出提交 A 范围的额外代码：

1. 在文件末尾添加了提交 A
2. 新提交在文件末尾的提交 A 之后添加了更多代码（低于提交 A 的更改）
3. 现在，当我们反转提交 A 中的更改时（使用 git apply -R -3），它​​会从提交 A 的开始到文件结尾进行清理，因为对于 git，代码最初是添加到文件末尾的

我们有数百个存储库，并定期从上游接收补丁。作业使用git apply --check <patch>. 如果没有错误，则应用补丁git apply <patch>并提交更改。如果有任何错误，补丁将被标记为conflict。然后将错误和冲突的补丁交付给我们的存储库维护人员。它们用于git apply --reject <patch>应用补丁和解决冲突。

以我之前的理解，git apply --reject是可靠的。但是，一位维护人员报告说，补丁的应用方式完全错误。一些新行被插入到意外函数中的块中，该函数恰好具有相同的上下文。还有其他一些错误的块。

例如，补丁中的块是

但是在应用的文件中，块是

维护者很可能没有注意到错位的行，这会导致构建错误甚至更严重的隐藏错误。git apply --3way <patch>尽管仍然存在冲突，但我让维护者尝试并按预期应用了补丁。

我的想法git apply --reject和git apply --3way行为不同，因为他们使用不同的算法。从结果来看，我想我们需要采用git apply --3way. 但我也担心--3way在某些情况下可能会出乎意料地工作。

为什么git apply --reject以看似错误的方式工作，而不是将块视为冲突？在我们的情况下哪个更好？有没有更好的解决方案来应用补丁？谢谢。