这个问题是关于git apply
有没有办法区分两者：它失败了，因为...
- 。修补程序已应用
- 。源代码真的很不同
我工作的目录不是 git 目录，因此我不能使用git log或其他东西。
我知道-R(反向)选项，因此我目前的解决方法是：
git apply abc.patch || git apply abc.patch -R --check && echo already applied
这样git apply abc.patch -R --check && git apply abc.patch只有在git apply abc.patch失败时才执行，然后检查它是否失败，因为补丁已经应用(git apply abc.patch -R --check)，如果是这种情况，它会回显"已经应用">
但是我不喜欢它，git的应用程序中没有类似内置解决方案的东西吗？
实际上，git apply --reverse --check是您正在寻找的"内置到git"解决方案。对于像另一个答案中描述的许多相同行的情况，您需要做的就是确保您的补丁文件具有更多/足够的上下文来消除歧义(例如，使用git diff -U60)。
示例：如果一个补丁说"删除这 50 行中的一行，留下 49 行"，则有明确定义的结果：
- 如果少于 49 行或超过 50 行，则修补程序不适用：
get apply --check和git apply --reverse --check都将失败。 - 对于其中的 49 行，补丁已经应用：
git apply --check将失败，git apply --reverse --check将成功。 - 对于其中的 50 行，补丁尚未应用：
git apply --check会成功，git apply --reverse --check会失败。 - 如果
get apply --check和git apply --reverse --check都成功，则需要增加修补程序的上下文以消除歧义。
您甚至可以以编程方式测试反复递增补丁的上下文，直到它按预期工作(如果您不是手动操作)。
简短的回答是否定的，或者至少不是一般的。
考虑一下：补丁是一组指示，说"删除此行"和"添加这些其他行"。 假设file的修补程序完整读取：
diff --git a/file b/file
index 87cdbbd..3d8696b 100644
--- a/file
+++ b/file
@@ -7,4 +7,3 @@ this file is dull
this file is dull
this file is dull
this file is dull
-this file is dull
换句话说，输入文件非常沉闷，至少在最后，它只是不断重复"这个文件很沉闷"。
对文件的更改是删除其中一行沉闷的行。上下文更多，同样沉闷的线条，然后是"文件结尾"。
自从补丁生成以来，有人修改了文件的顶部，使其不再只有 10(或 9)个沉闷的行，但它仍然以至少 4 条沉闷的行结尾。 该文件现在超过 50 行长，至少相对而言，大多数顶级文件都非常令人兴奋。
作为一个聪明的人，你能判断这个文件的补丁是否已应用吗？ 我要告诉您的是，补丁可能已应用，也可能未应用，以及其他更改，这些更改在文件顶部添加了许多令人兴奋的行。
如果你说不出来，你为什么会相信 Git 可以？ 我不了解你，但我无法判断添加令人兴奋的台词的变化是否也删除了最后沉闷的台词。
(现在，在某些情况下 - 特别是如果你有那index 87cdbbd..3d8696b 100644行 - 有一种方法可以告诉，前提是你还有一个文件的提交版本，其哈希ID为87cdbbd，因为现在我们可以提取该文件的特定版本。 但你没有说明你是否有索引行，如果有，你是否还有一个具有匹配哈希 ID 的 blob。