Does changing filename case breaks git's rename heuristic?

Hi all,

I may be mistaking a design decision as a bug, but I wanted to throw
this out to the list to make sure. I think that re-enacting it will be
the best way to explain it.

$ mkdir test
$ cd test
$ git init
$ cat > readme
This is a test file.
^D
$ git commit -am "first commit"
[master (root-commit) fae0d05] first commit
 1 files changed, 1 insertions(+), 0 deletions(-)

For personal reasons, I now want readme to be uppercase.

$ mv readme README
$ cat > README
This is the revised README.
$ git status -sb
## master
 M readme
$ git add README
$ git status -sb
## master
 M readme

At this point, I'm thinking that git is confused. Even though I've
added the README file, it still isn't staged. I follow up with the
obvious:

$ git add readme
$ git status -sb
## master
M  readme
$ git commit -m "change filename"
[master ecc009f] change filename
 1 files changed, 1 insertions(+), 1 deletions(-)

It kind of works, but not quite, since git still thinks the file is
called readme. I'd like to rename it, but whenever I run:

$ git mv readme README
fatal: destination exists, source=readme, destination=README

How about this:

$ mv README README.temp
$ git mv readme README
fatal: bad source, source=readme, destination=README

The only workable solution was this:

$ git mv readme readme.temp
$ git mv readme.temp README

I'm guessing this all has to do in some part with the logic behind
git's strategy for detecting renames. This case probably slipped under
the radar.

-Dan