'git add --patch' to include new files?

Question

When I run git add -p, is there a way for git to select newly made files as hunks to select??

So if I make a new file called foo.java, then run

Answer 1

Catshoes's answer includes:

When I tried git add -p someNewFile.txt on a new file (an untracked file), git would simply output No changes. and stop.
I had to tell git that I intended to track the new file first.

git add -N someNewFile.txt
git add -p

That should change soon with Git 2.29 (Q4 2020).

Recent versions of "git diff-files"^(man) shows a diff between the index and the working tree for "intent-to-add" paths as a "new file" patch;
"git apply --cached"^(man) should be able to take "git diff-files" and should act as an equivalent to "git add" for the path, but the command failed to do so for such a path.

See commit 4c025c6, commit e3cc41b (08 Aug 2020), and commit 7cfde3f (06 Aug 2020) by Raymond E. Pasco (juped).
^{(Merged by Junio C Hamano -- gitster -- in commit ca81676, 17 Aug 2020)}

apply: allow "new file" patches on i-t-a entries

^{Helped-by: Junio C Hamano
Signed-off-by: Raymond E. Pasco}

diff-files recently changed to treat changes to paths marked "intent to add" in the index as new file diffs rather than diffs from the empty blob.

However, apply refuses to apply new file diffs on top of existing index entries, except in the case of renames.
This causes "git add -p"^(man) , which uses apply, to fail when attempting to stage hunks from a file when intent to add has been recorded.

This changes the logic in check_to_create() which checks if an entry already exists in an index in two ways:

• first, we only search for an index entry at all if ok_if_exists is false;
• second, we check for the CE_INTENT_TO_ADD flag on any index entries we find and allow the apply to proceed if it is set.

---

And:

With Git 2.29 (Q4 2020), "add -p" now allows editing paths that were only added in intent.

See commit 75a009d (09 Sep 2020) by Phillip Wood (phillipwood).
^{(Merged by Junio C Hamano -- gitster -- in commit 458205f, 22 Sep 2020)}

add -p: fix editing of intent-to-add paths

^{Signed-off-by: Phillip Wood
Reported-by: Thomas Sullivan
Reported-by: Yuchen Ying}

A popular way of partially staging a new file is to run git add -N ^(man) and then use the hunk editing of git add -p^(man) to select the part of the file that the user wishes to stage.

Since 85953a3187 ("diff-files --raw: show correct post-image of intent-to-add files", 2020-07-01, Git v2.28.0-rc0 -- merge listed in batch #7) this has stopped working as intent-to-add paths are now show as new files rather than changes to an empty blob and git apply^(man) refused to apply a creation patch for a path that was marked as intent-to-add. 7cfde3fa0f ("apply: allow "new file" patches on i-t-a entries", 2020-08-06) fixed the problem with apply but it still wasn't possible to edit the added hunk properly.

2c8bd8471a ("checkout -p: handle new files correctly", 2020-05-27, Git v2.28.0-rc0 -- merge listed in batch #2) had previously changed add -p to handle new files but it did not implement patch editing correctly.
The perl version simply forbade editing and the C version opened the editor with the full diff rather that just the hunk which meant that the user had to edit the hunk header manually to get it to work.

The root cause of the problem is that added files store the diff header with the hunk data rather than separating the two as we do for other changes. Changing added files to store the diff header separately fixes the editing problem at the expense of having to special case empty additions as they no longer have any hunks associated with them, only the diff header.

The changes move some existing code into a conditional changing the indentation, they are best viewed with --color-moved-ws=allow-indentation-change (or --ignore-space-change works well to get an overview of the changes)