'git add --patch'包含新文件？

Question

当我运行时git add -p,有没有办法让git选择新制作的文件作为选择？

因此,如果我创建一个新文件foo.java,然后运行git add -p,git将不允许我选择要添加到索引中的文件内容.

Answer 1

当我尝试git add -p someNewFile.txt一个新文件(一个未跟踪的文件)时,git只会输出No changes.并停止.我不得不告诉git我打算先跟踪新文件.

git add -N someNewFile.txt
git add -p

但是,由于该文件未被跟踪,它将显示为一个无法拆分的巨型块(因为它全新!).那么,我需要将hunk编辑成更小的位.如果您对此不熟悉,请查看此参考以开始使用.

更新 - Hunk编辑信息 我想更新这个以防上述参考文献消失.由于新文件未跟踪,因此git add -p会将文件中的每一行显示为一个大块中的新行.然后它将询问您对该块的操作,并给出以下提示:

Stage this hunk [y,n,q,a,d,/,e,?]?

假设您不想提交整个块​​(因此,整个文件;因为我不确定您为什么要git add -p在这种情况下使用？),您将需要指定选项e以告诉git您要编辑大块头.

一旦你告诉git你想要编辑大块,它应该让你进入你选择的编辑器,这样你就可以进行更改.所有行都应以a为前缀,+git #在文件末尾有一些解释性注释(带有前缀a ).只需删除初始提交文件时不需要的任何行.然后保存并退出编辑器.

Git对git的大块选项的解释:

y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
g - select a hunk to go to
/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help

Answer 2

要对每个新文件执行此操作,您可以运行:

git add -N .
git add -p

如果您想经常使用它,可以在以下位置创建别名~/.bashrc:

alias gapan='git add --intent-to-add . && git add --patch'

注意:如果你使用一个空的新文件,git将无法修补它并跳到下一个.

Answer 3

Catshoes的回答包括：

当我尝试git add -p someNewFile.txt处理一个新文件（一个未跟踪的文件）时，git 只会输出 No changes。并停止。
我不得不告诉 git 我打算先跟踪新文件。

git add -N someNewFile.txt
git add -p

Git 2.29（2020 年第四季度）应该很快就会改变。

“ git diff-files” ^（man）的最新版本将“意图添加”路径的索引和工作树之间的差异显示为“新文件”补丁；
" git apply --cached" ^{( man )}应该能够采用 " git diff-files" 并且应该作为git add路径的等效于 " "，但是对于这样的路径，命令没有这样做。

请参阅Raymond E. Pasco ( ) 的提交 4c025c6、提交 e3cc41b（2020 年 8 月 8 日）和提交 7cfde3f（2020 年 8 月 6 日）。^{（由Junio C Hamano合并-- --在提交 ca81676 中，2020 年 8 月 17 日）}juped
gitster

apply: 在 ita 条目上允许“新文件”补丁

^{帮助者：Junio C Hamano
签字人：Raymond E. Pasco}

diff-files 最近更改为将对索引中标记为“意图添加”的路径的更改视为新文件差异而不是来自空 blob 的差异。

但是，apply拒绝在现有索引条目之上应用新文件差异，重命名的情况除外。
这会导致使用 apply 的" git add -p" ^{( man )}在记录了添加意图时尝试从文件暂存大块时失败。

这改变了check_to_create()以两种方式检查索引中是否已存在条目的逻辑：

• 首先，如果ok_if_exists为假，我们只搜索索引条目；
• 其次，我们检查CE_INTENT_TO_ADD我们找到的任何索引条目上的标志，如果设置了，则允许应用程序继续进行。

和：

在 Git 2.29（2020 年第四季度）中，“ add -p” 现在允许编辑仅在意图中添加的路径。

请参阅Phillip Wood ( ) 的commit 75a009d (09 Sep 2020 )。^{（由Junio C Hamano合并-- --在2020 年 9 月 22 日提交 458205f 中）}phillipwood
gitster

add -p：修复意图添加路径的编辑

^{签字人：Phillip Wood
报道人：Thomas Sullivan
报道人：Yuchen Ying}

的部分分期新文件的流行方法是运行^（人），然后用的大块编辑^（人），选择文件的用户希望阶段的一部分。git add -N <path>git add -p

自85953a3187（“diff-files --raw：显示意图添加文件的正确后图像”，2020 年 7 月 1 日，Git v2.28.0-rc0 --合并在第 7 批中列出）以来，它已停止工作因为意图添加路径现在显示为新文件而不是对空 blob 的更改，并且^{( man )}拒绝为标记为意图添加的路径应用创建补丁。7cfde3fa0f（“应用：在 ita 条目上允许“新文件”补丁”，2020 年 8 月 6 日）修复了应用问题，但仍然无法正确编辑添加的大块。git apply

2c8bd8471a（“ checkout -p：正确处理新文件”，2020 年 5 月 27 日，Git v2.28.0-rc0 --合并在第 2 批中列出）之前已更改add -p为处理新文件，但它没有正确实现补丁编辑。
perl 版本只是禁止编辑，C 版本使用完整差异打开编辑器，而不是只打开大块头，这意味着用户必须手动编辑大块头标题才能使其工作。

问题的根本原因是添加的文件将 diff 标头与大块数据一起存储，而不是像我们对其他更改那样将两者分开。更改添加的文件以单独存储 diff 标头解决了编辑问题，但代价是必须进行特殊情况下的空添加，因为它们不再有任何关联的大块头，只有 diff 标头。

更改将一些现有代码移动到有条件的更改缩进中，最好使用--color-moved-ws=allow-indentation-change（或--ignore-space-change很好地了解更改的概述）

Git 2.32（2021 年第二季度）增加了一点清晰度：

请参阅Peter Oliver ( ) 的commit 7a14acd (27 Apr 2021 )。^{（由Junio C Hamano合并-- --在提交 e60e9cc 中，2021 年 5 月 7 日）}mavit
gitster

doc: 指向补丁格式文档中的 diff 属性

^{签字人：彼得·奥利弗}

从使用 diff 相关命令生成补丁文本的文档中，请参阅 diff 属性的文档。

此属性会影响补丁的生成方式，但这之前在^{( man )}联机帮助页中并未提及。git-diff

diff-generate-patch现在包括在其手册页中：

5. Hunk 标头提到了 Hunk 适用的函数的名称。有关gitattributes如何针对特定语言进行定制的详细信息，请参阅“定义自定义 hunk-header” 。

Answer 4

还有一个非常相似的方法使用--cached标志......

1)将未暂存的更改转换为暂存的，就像添加的文件一样。

git add edited-file.txt
git add new-file.txt
git add directory-of-changes/

2）查看差异（注意：您可以包括编辑和新文件）。

git diff --cached

3)创建补丁。

git diff --cached > my_patch_file.patch

Answer 5

git add -p 实际上是关于对已经跟踪的文件添加更改。

以交互方式选择要添加的文件的命令是git add -i。例如：

$ git add -i

*** Commands ***
  1: status   2: update   3: revert   4: add untracked
  5: patch    6: diff     7: quit     8: help
What now> a
  1: another-new.java
  2: new.java
Add untracked>> 2
  1: another-new.java
* 2: new.java
Add untracked>> 
added one path

*** Commands ***
  1: status   2: update   3: revert   4: add untracked
  5: patch    6: diff     7: quit     8: help
What now> q
Bye.
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   new.java

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        another-new.java

（真正的命令具有我无法在此处剪切和粘贴的颜色，因此它比看起来更好）

实际上，p的ATCH命令git add -i不一样git add -p，所以第二个是第一个的子集（尽管我承认我爱add -p和恨add -i我自己！）。