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