Re: Does changing filename case breaks git's rename heuristic?

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Aug 27, 2010, 08:00 UTC
Message-ID: <4C777090.2000107@drmicha.warpmail.net>
In-Reply-To: <AANLkTinxvj85Jzb-ykK0=MmRHkz8aQzmVxexC8H+Xgno@mail.gmail.com>

Dan Loewenherz venit, vidit, dixit 27.08.2010 06:57:

Show 15 quoted lines

> 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(-)

? You have not added any file, so git won't commit anything (not even with -a). The above can't be a complete transcription. I assume you've added readme with the content above.

> 
> For personal reasons, I now want readme to be uppercase.
> 
> $ mv readme README

Here's where using "git mv" would have been the easier choice, followed by commit.

> $ cat > README
> This is the revised README.

Renaming and changing the content completely in one step will always trip up git's rename detection. You should rename, commit, change, commit, unless the change affects a small portion of the file only.

> $ git status -sb
> ## master
>  M readme

Again, this can't be a complete transcript. The above would lead to

 D readme
?? README

Show 6 quoted lines

> $ git add README
> $ git status -sb
> ## master
>  M readme
> 
> At this point, I'm thinking that git is confused. Even though I've

Are you possibly using a case-challenged file system? Is this maybe on a Mac with HFS or Win with NTFS?

Michael