File doesn′t get into the commit after using git add -N

Question

I want to commit a Python module’s __init__.py file, which, on my disk, already contains code. However, for the current commit, I wanted to add it empty, as this part of the code is yet to be tested. Thus, I used

$ git add -N __init__.py

The file is there in the output of git status, but if I issue git commit, all other files gets into the commit except __init__.py, which, in turn, remains in the index according to git status.

The man page of git-add says for -N that

Record only the fact that the path will be added later. An entry for the path is placed in the index with no content.

Is there a way to circumvent this will be added later part, i.e. add the file empty without temporarily deleting its content?

Edit: This happens with current (2.2.0) Git. With 1.7.1 and a small test repo, I get an error:

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   b
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   b
#
$ git commit -m 'test'
b: not added yet
error: Error building trees

Answer 1

This should be fixed with Git 2.5 (Q2 2015), meaning git commit won't try to include the new file "intended to be added later".
See commit d95d728 by Nguyễn Thái Ngọc Duy (pclouds) (merged in d0c692263)

diff-lib.c: adjust position of i-t-a entries in diff

Problem:

Entries added by "git add -N" are reminder for the user so that they don't forget to add them before committing. These entries appear in the index even though they are not real.
Their presence in the index leads to a confusing "git status" like this:

On branch master
Changes to be committed:
        new file:   foo

Changes not staged for commit:
        modified:   foo

If you do a "git commit", "foo" will not be included even though "status" reports it as "to be committed".

Solution:

This patch changes the output to become

On branch master
Changes not staged for commit:
        new file:   foo

no changes added to commit

In other words:

• Treat such paths as "yet to be added to the index but Git already know about them";
• "git diff HEAD" and "git diff --cached HEAD" should not talk about them, and
• "git diff" should show them as new files yet to be added to the index.

---

Update Q4 2016:

commit: fix empty commit creation when there's no changes but ita entries

(ita or i-t-a is "intent to add")

See commit 2c49f7f, commit 018ec3c, commit b42b451, commit 425a28e (24 Oct 2016) by Nguyễn Thái Ngọc Duy (pclouds).
^{(Merged by Junio C Hamano -- gitster -- in commit 6503602, 27 Oct 2016)}

When new paths were added by "git add -N" to the index, it was enough to circumvent the check by "git commit" to refrain from making an empty commit without "--allow-empty".
The same logic prevented "git status" to show such a path as "new file" in the "Changes not staged for commit" section.

git diff man page now includes:

--ita-invisible-in-index:

By default entries added by "git add -N" appear as an existing empty file in "git diff" and a new file in "git diff --cached".
This option makes the entry appear as a new file in "git diff" and non-existent in "git diff --cached".

This option could be reverted with --ita-visible-in-index.

Both options are experimental and could be removed in future.

---

Update Q1 2018 (Git 2.16.x/2.17), git status improves again.
"git status", after moving a path in the working tree (hence making it appear "removed"), and then adding with the -N option (hence making that appear "added") detected it as a rename, but did not report the old and new pathnames correctly.

See commit 176ea74, commit 5134ccd, commit ea56f97, commit 98bc94e, commit 06dba2b, commit 6de5aaf (27 Dec 2017) by Nguyễn Thái Ngọc Duy (pclouds).
Helped-by: Igor Djordjevic (boogisha).
^{(Merged by Junio C Hamano -- gitster -- in commit bc3dca0, 23 Jan 2018)}

Note: i-t-a or ita is "intended to add".

wt-status.c: handle worktree renames

Before 425a28e (diff-lib: allow ita entries treated as "not yet exist in index" - 2016-10-24, Git 2.11.0-rc0) there are never "new files" in the index, which essentially disables rename detection because we only detect renames when a new file appears in a diff pair.

After that commit, an i-t-a entry can appear as a new file in "git diff-files".
But the diff callback function in wt-status.c does not handle this case and produces incorrect status output.

---

Update Q4 2018 with Git 2.20, git status avoid displaying multiple renames on the same target.

See commit 3e73cc6 (27 Sep 2018) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster -- in commit 98f3f00, 16 Oct 2018)}

commit: fix erroneous BUG, 'multiple renames on the same target? how?'

builtin/commit.c:prepare_to_commit() can call run_status() twice if using the editor, including status, and the user attempts to record a non-merge empty commit without explicit --allow-empty.
If there is also a rename involved as well (due to using 'git add -N'), then a BUG in wt-status.c is triggered:

BUG: wt-status.c:476: multiple renames on the same target? how?

The reason we hit this bug is that both run_status() calls use the same struct wt_status * (named s), and s->change is not freed between runs. Changes are inserted into s with string_list_insert, which usually means that the second run just recomputes all the same results and overwrites what was computed the first time.