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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html