标签: git-apply

根据官方git 文档：

git apply
    --ignore-space-change, --ignore-whitespace
       When applying a patch, ignore changes in whitespace in context lines if necessary.
       Context lines will preserve their whitespace, and they will not undergo whitespace fixing
       regardless of the value of the --whitespace option. New lines will still be fixed, though.

然而，基本测试表明这是一个该死的谎言。

复制步骤：

1. somefile.txt使用以下内容 创建：
   • 第 1 行：任何您想要的文本
   • 第 2 行：任何非零数量的空格
   • 第 3 行：任何您想要的文本
2. git add somefile.txt
3. cp somefile.txt somefile.orig.txt
4. 调整somefile.txt：
   • 第 1 行：进行任何您想要的更改
   • 第 2 行：删除所有空格（现在将是空行）
   • 第 3 …

git mergetool很棒（就我而言，我使用 kdiff3）。但是，无法使用它来解决来自git am或git apply（甚至与patch命令）的冲突。实际上，mergetool 在git am使用修改版本和补丁时需要 3 个文件才能工作（基本版本和两个修改版本）。

你知道一种git mergetool用于与产生的冲突的方法git am吗？

我认为有必要从修改版本和补丁中猜测基本文件。如果单独考虑每个块，看起来很棘手，但并非不可能。

我在我的目录中修改了一个文件（或一些文件），并且我曾经git add从文件中暂存一些更改行，但不是所有更改的行。

我可以git diff --staged my-file用来查看更改内容的差异。 git diff --staged my-file忽略已更改但未上演的行。这是输出的示例git diff --staged my-file

diff --git a/ens/cours/ens_cours_JN.csv b/ens/cours/ens_cours_JN.csv
index dcea574..ff33469 100644
--- a/ens/cours/ens_cours_JN.csv
+++ b/ens/cours/ens_cours_JN.csv
@@ -24,6 +24,7 @@ SCALIN_E;EPITA;préparation pédagogique;JN;ING1;2020-05-13;;False;True;PT4H;;
 SCALIN_E;EPITA;préparation pédagogique;JN;ING1;2020-05-20;;False;True;PT4H;;
 SCALIN_E;EPITA;préparation pédagogique;JN;ING1;2020-05-27;;False;True;PT4H;;
 SCALIN_E;EPITA;préparation pédagogique;JN;ING1;2020-06-03;;False;True;PT4H;;
+SCALIN_E;EPITA;préparation pédagogique;JN;ING1;2020-06-03;;False;True;PT4H;;commit this line
 THLR;EPITA;préparation pédagogique;JN;ING1;2020-07-20;;False;True;PT8H;;Recording TDs
 THLR;EPITA;préparation pédagogique;JN;ING1;2020-07-21;;False;True;PT8H;;Recording TDs
 THLR;EPITA;préparation pédagogique;JN;ING1;2020-07-22;;False;True;PT8H;;Recording TDs

问题：如何生成要提交的文件的文本？我想要一个签入挂钩，以便在允许提交之前最终处理该文件。

我怀疑有一些简单的咒语使用git apply. 但是，简单使用git apply会产生以下诊断消息。

jnewton@Marcello cours % git diff --staged > ens_cours_JN.csv.patch
git diff --staged > ens_cours_JN.csv.patch
jnewton@Marcello …

我一直都diff -b在制作补丁时会做补丁git repo。

1. 两者之间有什么区别，git diff / git format-patch内部是否也使用linux / unix diff命令？（我知道之间的区别git diff/git format-patch）
2. 此外，与的修补方式patch -p1有何不同git apply。我可以应用由diff命令（diff -b）生成的补丁并使用进行应用git diff吗？
3. 与之一起使用git diff/apply时是一种好习惯git吗？我一直在使用diff/patch，从未遇到任何问题。

如果我对上述事情的知识不足，请指正。

假设补丁是从过去的特定提交创建的，并且不再适用于HEAD。

我如何找到HEAD历史记录中的第一个提交或更好的最后一个提交，在此补丁中加上“ git apply”？也许有git bisect吗？但是哪个命令会告诉我是否有补丁？

理想情况下，除非有冲突，否则我想返回到该提交，应用补丁，然后基于原始HEAD或与之合并，然后再次进行比较以创建新补丁。在此之后，我想回到原始的HEAD，以便可以继续安装更多补丁。

背景：有许多补丁需要重新发布...（是的，在某些生态系统中，补丁仍然很重要。）

我需要编辑一个凌乱的commit提交，该提交只会在随后的几行中更改一个单词，保留其中一些更改，而删除其他更改。这些更改很容易在中看到git diff --word-diff，并且以这种格式，我可以轻松地编辑大块以完成我打算做的事情，但是现在我有了一个像这样的文件

diff --git a/cldf/forms.csv b/cldf/forms.csv
index 46c12a4..0374ece 100644
--- a/cldf/forms.csv
+++ b/cldf/forms.csv
@@ -1783,8 +1783,8 @@ ID,Lect_ID,Concept_ID,Form_according_to_Source,Form,Local_Orthography,Segments,C
1782,adan1251-lawah,day,dil?l?,dil?l?,dilele,d i l ? l ?,Lit. 'all day'.,datasets_Adang_Lawahing_tsv
1783,adan1251-lawah,day,w?d saha,w?d_saha,wed saha,w ? d _ s a h a,midday' lit. 'hot sun',datasets_Adang_Lawahing_tsv
1784,adan1251-lawah,morning,lalami,lalami,lalami,l a l a m i,,datasets_Adang_Lawahing_tsv
1785,adan1251-lawah,yesterday,?u:mi,?u?mi,[-umi-]{+'umi+},? u? m i,,datasets_Adang_Lawahing_tsv
1786,adan1251-lawah,day_before_yesterday,?otari? alumi,?otari?_alumi,[-otaring-]{+'otaring+} alumi,? o t a r i ? _ a l u m i,,datasets_Adang_Lawahing_tsv
1787,adan1251-lawah,tomorrow,dil?l?,dil?l?,dilele,d i l ? l ?,,datasets_Adang_Lawahing_tsv
1788,adan1251-lawah,day_after_tomorrow,a:lu,a?lu,alu,a? l u,,datasets_Adang_Lawahing_tsv
1789,adan1251-lawah,twilight_dawn,lalami,lalami,lalami,l a l a …

我们收到了一个大补丁，修改了大约 17000 个文件。其大小为5.2G。当用 涂抹贴剂时git apply -3，12小时后仍未完成。

我们将每个文件的补丁分成更小的补丁，然后一一应用它们，这样至少我们可以看到进度。

再次卡在一个文件补丁上，仍然有111M那么大。它修改 HTML 文件。

我们将此文件补丁分成每个块更小的补丁，并获得大约 57000 个块补丁。每个块补丁大约需要 2-3 秒，因此比应用文件补丁需要更多时间。我会尝试将其分成更多块。

有什么方法可以有效地应用这么大的补丁吗？谢谢。

更新：

正如@ti7建议的，我尝试了一下patch，它解决了问题。

就我而言，我们有两种大补丁。

一种是添加/删除大型二进制文件，并且二进制文件的内容作为文本包含在补丁中。其中一个二进制文件大小为 188M，删除它的补丁大小为 374M。

另一种是修改大文本，有数百万次的删除和插入。其中一个文本文件前70M，后162M。补丁大小为181M，有2388623个插入和426959个删除。

经过一些测试，我认为这里的“大”描述的是插入和删除的数量。

对于二进制补丁，

• git apply -3, 7 秒
• git 应用，6 秒
• 补丁，5 秒

对于文本补丁，

• git apply -3，卡住了，10分钟后还没完成
• git apply，卡住了，10分钟后还没完成
• 补丁，3秒

该二进制文件仅包含 1 处插入和/或 1 处删除。git apply或者patch可以在几秒钟内完成。一切都可以接受。

文本插入和删除过多。显然，patch在这种情况下要好得多。我阅读了一些帖子patch并了解到某些版本patch无法添加/删除/重命名文件。幸运的是，patch在我的机器上运行良好。

因此，我们将一体化补丁拆分为每个文件的更小的补丁。我们timeout 10s git apply -3 file_patch先尝试一下。如果无法在 10 秒内完成，请尝试timeout 10s patch -p1 < …

我需要为最后N次提交创建一个补丁文件,并将它们作为单独的提交应用到另一个分支.对于N = 3,我假设我必须这样做:

git diff HEAD~3 HEAD~2 >> diff1
git diff HEAD~2 HEAD~1 >> diff2
git diff HEAD~1 HEAD >> diff3

然后分别将它们应用于另一个分支:

git apply diff1
(push)
git apply diff2
(push)
git apply diff3

有没有更短的方法来做到这一点？

我有一个基于熔丝的文件系统,为了改进它我需要实现这种方法 https://lwn.net/Articles/674286/

我明白我应该git apply < patch >,问题是我不明白应该应用这个补丁的确切位置？

补丁试图修改几个文件,例如:

a/fs/fuse/Makefile
a/fs/fuse/dev.c
b/fs/fuse/dev.c
a/fs/fuse/dir.c
b/fs/fuse/dir.c
etc..

这是我用locate命令找不到的,也尝试丢失'a'和'b'前缀并找到了makefile.

• 注意:已安装libfuse-dev

我有这个补丁文件，它包含一堆修改，我想将其应用于git分支。但是，我不想对所有这些修改都进行一次唯一提交，而是想将其分为2或3次提交。

我知道我可以通过首先应用补丁来实现此目的，然后进行交互式添加（逐块），如下所示：

git apply mypatch
git add -p

我只是想知道是否可以在一个git命令中做到这一点。我发现没有什么的联机帮助页git apply，也不在git add。

编辑

我不认为此问题应被视为具有多个命令的Git别名语法的重复，因为该问题（及其答案）不需要涉及传递给别名的参数。