Why does git show "dev/null" in status after interactive add of renamed file?

Question

I get an unexpected appearance of "dev/null" in my git status output after interactively adding a patch for a file that was renamed. I'm wondering if this is expected and there is some good reason for this behavior, or if this could be a bug.

Below is a simple illustration of how to reproduce this. In my real-world scenario, it's a bit more complicated and there's a good reason why I'm using git add -p, but I was able to boil it down to this minimal example:

$ git init test
Initialized empty Git repository in /local_disk/tmp/test/.git/
$ cd test
$ echo "foo" > foo
$ git add foo
$ git commit -m 'Add foo'
[master (root-commit) 3643b5d] Add foo
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 foo
$ mv foo bar
$ git add -p
diff --git a/foo b/foo
index 257cc56..0000000
--- a/foo
+++ /dev/null
@@ -1 +0,0 @@
-foo
Stage this hunk [y,n,q,a,d,/,e,?]? y

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#       new file:   dev/null
#       deleted:    foo
#
# Changed but not updated:
#   (use "git add/rm ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#       deleted:    dev/null
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#       bar

What is with the "new file: dev/null" and "deleted file: dev/null"? I would expect this to result in exactly the same thing as if I had done:

$ mv foo bar
$ git rm foo
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#       deleted:    foo
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#       bar

I am using Git version 1.6.5.5, and have also reproduced it in 1.6.5.4. I was unable to reproduce it in my Cygwin environment which has Git at version 1.6.1.2.

Answer 1

As thenduks mentions, you shouldn't be trying to git add the file removal. git add the new file, git rm the old file (or git mv old new to take the simple approach). On the other hand, git should either complain about what you're doing or not get confused and try to add a non-existent dev/null file.

Update
git add -p is indeed a valid method to stage file removals, but it looks like a bug was introduced to git apply when fixing a different git apply bug.

Update
I can reproduce it on Linux with 1.6.1.2, so it may be that the cygwin git is what differs from the normal behavior. In that case, the previously mentioned bug-fix may not have introduced this behavior and the working git add -p may be specific to cygwin's git. I've been trying to bisect to find where git add -p started failing.

Update
Turns out it was rather a bug in the interactive aspect of git add which Jeff King has proposed patches for.