Currently the hashed directories in .git-annex allow for upper and lower case directory names... on linux (or any case sensitive filesystem) the directory names such as 'Gg' and 'GG' are different and unique. However on systems like OSX (and probably windows if it is ever supported) the directory names 'Gg' is the same as 'GG'

In one of the annex'd repos that I have this has occured...

<pre>
$ git add -i                                                                                          
           staged     unstaged path
  1:    unchanged        +1/-1 .git-annex/GM/GV/WORM-s183630166-m1301072171--somefile.log
  2:    unchanged        +1/-1 .git-annex/Gm/GV/WORM-s183630166-m1301072171--somefile.log
</pre>


this has somewhat confused git when it tries to stage/merge files, I didn't notice this at first, but it is definately a problem for someone using case insensitive filesystems  like the default OSX HFS+ formats or vfat/fat32.

> I feel a bit stupid to not have considered case-insensative filesystems.
> They are just so far from where I have lived for 20 years that it's hard
> to keep them in mind.
> 
> I guess that
> [[git-annex_has_issues_with_git_when_staging__47__commiting_logs]] is
> somehow a consequence (or cause?) of this, but I don't quite understand
> how this is causing git to fail to stage files, or stage the same file
> twice under different capitalizations. git-annex always will run git add
> on the path with the "correct" capitalization. So unless something else
> has added the path with the other capitalization (perhaps git add
> .git-annex manually?) I don't understand how you get to this state.
> --[[Joey]]

>> I think I got myself into this situation when I copied some files over from a HFS+ partition to a GPFS network share (which is pretty posix compliant) over samba. It probably is related to the [[git-annex_has_issues_with_git_when_staging__47__commiting_logs]]. I thought they were unique enough to have two bug reports logged as one is a git behavioural thing and the other is git-annex specific.

>>> If you copied `.git/` over, perhaps you got a git repo without
>>> core.ignorecase set right for the filesystem it landed on?

>>>> I usually git clone or do a fresh repository and pull things in, I was also unaware of this ignorecase setting as well.

>>> 
>>> Something like this might reproduce it:

<pre>
# mkdir test; cd test; git init
# git config core.ignorecase false
# mkdir Foo
# touch Foo/bar
# git add Foo/bar
# git add foo/bar
# git add fOo/bar
# git status
# touch foo/other
# git add fOo/other
# git status
</pre>

>>>> And then either git commit or git clone would probably get confused
>>>> if it thought 3 distinct files had been committed.
>>>> --[[Joey]]

>>>>> Doing the above test on a HFS+ partition yields this

<pre>
## with ignorecase=false
commit bb024c6fd7482b2d10f60ae899cb7a949aca1ad8
Author: Jimmy Tang <jtang@exia>
Date:   Sun Mar 27 18:40:24 2011 +0100

    commit

diff --git a/Foo/bar b/Foo/bar
new file mode 100644
index 0000000..e69de29
diff --git a/fOo/bar b/fOo/bar
new file mode 100644
index 0000000..e69de29
diff --git a/fOo/other b/fOo/other
new file mode 100644
index 0000000..e69de29
diff --git a/foo/bar b/foo/bar
new file mode 100644
index 0000000..e69de29
</pre>

>>>>> and without changing ignorecase

<pre>
commit 909a089158ffb98f8e91f98905e2bfdc7234666f
Author: Jimmy Tang <jtang@exia>
Date:   Sun Mar 27 18:46:57 2011 +0100

    commit

diff --git a/Foo/bar b/Foo/bar
new file mode 100644
index 0000000..e69de29
diff --git a/Foo/other b/Foo/other
new file mode 100644
index 0000000..e69de29
</pre>

> Closing this bug, as it seems I have dealt with it adequately now.
> [[done]]
> --[[Joey]]