从补丁中删除索引 header 行的含义
Implications of removing the index header line from patch
上下文
我有一个 git 存储库（“parent 存储库”），其中包含我在另一个存储库（“内部存储库”）中使用 git diff --binary sometag 生成的 .patch 文件). parent 回购是 public 并开放请求请求。
根据 the docs，此文件包含每个更改的 header 行，如下所示：
index <hash>..<hash> <mode>
这意味着每次两个协作者接触同一个文件（即使在完全不同的行中）时，生成的哈希值也会不同，因此索引 header 会发生变化，从而导致可以避免的合并冲突。
我试图删除这些索引 headers 并且 git apply 似乎仍然工作得很好。
问题
删除索引 header 行是否有任何（隐藏的）影响？
它会导致二进制文件出现问题吗？
我假设 git apply 工具出于优化原因只会查看散列。即：“当你已经有了生成的文件时，不要为差异而烦恼”。
我知道模式 header 通常嵌入在索引 header 中，为了我的目的，可以缺少此信息。
Are there any (hidden) implications that come with the removal of the index header lines?
他们并不是真的隐藏，他们只是不会伸出手来打你的脸（不像Git的索引方式与 .gitignore).
互动
I assume the git apply tool will just look at the hashes for optimization reasons.
实际上恰恰相反。 apply 命令被赋予一个差异，并尝试将该差异应用于工作树 and/or 索引中的现有文件。这些差异具有 context 以及 changes 并且上下文 and/or 更改可能与现有文件不匹配（ s) 要应用差异的。如果我们应该添加：
(the BEST)
在第 12 行和第 13 行之间，应该是
one ice cream flavor
is chocolate
但现在他们阅读：
the odors of skunks
and ferrets
好吧，也许那不再是最好的了，是吗？
无论如何，如果事情看起来很可疑，Git 可以使用 index 行在您自己的本地存储库中四处寻找，试图找出文件的样子 before 添加了差异。如果它可以这样做——如果它可以找到 原始 文件——然后它可以将补丁 应用到 原始文件。它现在有三个文件：
- 原始文件，通过
index行找到；
- 更新后的文件，通过将补丁 应用于 原始文件而获得成功，因为
index 行提供了实际的原始文件，因此补丁匹配；和
- 您的文件版本。
有了单个文件的这三个版本，Git 现在可以对那个文件进行全面的三向合并，就像 git merge 所做的那样。 Git 可以找出补丁不匹配的原因是否是因为行移动了——所以现在可以将补丁应用到 correct 行，这可能是行例如，52 和 53 而不是 12 和 13 — 或者如果是因为您进行了冲突更改，现在存在合并冲突。 （也许你正确地将这些硫醇化合物识别为最难闻的东西，尽管尸胺和腐胺 give them a run for the money。）
... using git diff --binary sometag ...
来自 Git 的 binary 补丁要求您拥有正确的原像（index 行给出的项目）。没有索引行，假设我正确阅读 the source，Git 将拒绝应用补丁，使补丁本身无用。如果你要删除索引行，你还不如删除二进制补丁。
上下文
我有一个 git 存储库（“parent 存储库”），其中包含我在另一个存储库（“内部存储库”）中使用 git diff --binary sometag 生成的 .patch 文件). parent 回购是 public 并开放请求请求。
根据 the docs，此文件包含每个更改的 header 行，如下所示：
index <hash>..<hash> <mode>
这意味着每次两个协作者接触同一个文件（即使在完全不同的行中）时，生成的哈希值也会不同，因此索引 header 会发生变化，从而导致可以避免的合并冲突。
我试图删除这些索引 headers 并且 git apply 似乎仍然工作得很好。
问题
删除索引 header 行是否有任何（隐藏的）影响？ 它会导致二进制文件出现问题吗？
我假设 git apply 工具出于优化原因只会查看散列。即：“当你已经有了生成的文件时，不要为差异而烦恼”。
我知道模式 header 通常嵌入在索引 header 中，为了我的目的，可以缺少此信息。
Are there any (hidden) implications that come with the removal of the index header lines?
他们并不是真的隐藏，他们只是不会伸出手来打你的脸（不像Git的索引方式与 .gitignore).
I assume the
git applytool will just look at the hashes for optimization reasons.
实际上恰恰相反。 apply 命令被赋予一个差异，并尝试将该差异应用于工作树 and/or 索引中的现有文件。这些差异具有 context 以及 changes 并且上下文 and/or 更改可能与现有文件不匹配（ s) 要应用差异的。如果我们应该添加：
(the BEST)
在第 12 行和第 13 行之间，应该是
one ice cream flavor
is chocolate
但现在他们阅读：
the odors of skunks
and ferrets
好吧，也许那不再是最好的了，是吗？
无论如何，如果事情看起来很可疑，Git 可以使用 index 行在您自己的本地存储库中四处寻找，试图找出文件的样子 before 添加了差异。如果它可以这样做——如果它可以找到 原始 文件——然后它可以将补丁 应用到 原始文件。它现在有三个文件：
- 原始文件，通过
index行找到； - 更新后的文件，通过将补丁 应用于 原始文件而获得成功，因为
index行提供了实际的原始文件，因此补丁匹配；和 - 您的文件版本。
有了单个文件的这三个版本，Git 现在可以对那个文件进行全面的三向合并，就像 git merge 所做的那样。 Git 可以找出补丁不匹配的原因是否是因为行移动了——所以现在可以将补丁应用到 correct 行，这可能是行例如，52 和 53 而不是 12 和 13 — 或者如果是因为您进行了冲突更改，现在存在合并冲突。 （也许你正确地将这些硫醇化合物识别为最难闻的东西，尽管尸胺和腐胺 give them a run for the money。）
... using
git diff --binary sometag...
来自 Git 的 binary 补丁要求您拥有正确的原像（index 行给出的项目）。没有索引行，假设我正确阅读 the source，Git 将拒绝应用补丁，使补丁本身无用。如果你要删除索引行，你还不如删除二进制补丁。