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...
$ 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
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/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/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:
# 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
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
## with ignorecase=false commit bb024c6fd7482b2d10f60ae899cb7a949aca1ad8 Author: Jimmy Tang 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
and without changing ignorecase
commit 909a089158ffb98f8e91f98905e2bfdc7234666f Author: Jimmy Tang 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