Problems with file name case on Windows.

Under Cygwin, if you add a file "a" in one commit, then rename the file to "A" and commit again, both files will be in the new commit. Running the following line under Cygwin produces a commit with both files ("a" and "A"). Running it on Linux produces a commit with one file ("A"), as expected.

git init; git config core.ignorecase false; touch a; git add a; git commit -m a; mv a A; git add -A; git commit -m A

The problem seems to be with the "git add -A" part, since it is possible to get around the problem by running "git add A" followed by "git rm a" (or by using lower-level commands, I suppose). What are the chances of getting this fixed? It's mostly annoying when importing existing code where it's harder to use the add-rm workaround, since you don't know which files have changed file name case.

Hi,

On Fri, Apr 23, 2010 at 4:54 AM, martinvz <martin.von.zweigbergk@gmail.com> wrote:

Have you tried

  git mv a A; git commit -m A

instead of

  mv a A; git add -A; git commit -m A

?

Am 22.04.2010 22:54, schrieb martinvz:

The safe way to achieve your goal is:

   git mv a b
   git mv b A
   git commit

-- Hannes

Thanks, I had forgotten about "git mv". Still, when you receive just a tarball of code (actually from another VCS in my case), you would have to figure out which files had been renamed, before you could run the command, so it is not very useful in scripting in this case. Maybe what I could/should do is something like "git rm -rf *; <untar> ; git add -A"?

/Martin