Why does git-status show an updated binary file with a new name as a rename?

Question

When dealing with binary files git seems to consider replacing a file with another, modified, file a rename. This happens e.g. when replacing foo-1.0.1.jar with foo-1.0.3.jar or with the following test-case:

$ dd if=/dev/urandom of=test.dat bs=1024 count=10
$ md5sum test.dat
8073aef704e9df13b44818371ebbcc0b  test.dat
$ git add test.dat && git commit -m 'add binary file'
$ mv test.dat test2.dat
$ git rm test.dat
$ dd if=/dev/urandom of=test2.dat bs=1 count=1 conv=notrunc
$ md5sum test2.dat
21e1ac3ab9ba50c9dad9171f9de7232d  test2.dat
$ git add test2.dat

Now I clearly have a file with new contents (at least partially) and a new name. However, git considers this a rename in git status:

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       renamed:    test.dat -> test2.dat

• What's the reason for this, e.g. how similar do those two files have to be? It doesn't seem to happen if test2.dat contains completely different data.
• Does it have any disadvantages except looking somewhat awkward? The actual data seem to be perfectly fine; when checking out the previous revision I do get the correct file for that rev.

Answer 1

Git doesn't actually store renames, it just stores a new tree with one file deleted and another one added. Git commands that compare trees (git diff, git log, git status) detect renames based on content.

For some reason the rename detection fires for your files. Maybe their contents are similar if you've depleted the entropy in /dev/urandom?

Edit: See e.g. How does git detect similar files, for its rename detection? for details about rename detection.