summaryrefslogtreecommitdiff
path: root/doc/bugs/git-annex_directory_hashing_problems_on_osx.mdwn
blob: 2e6b138c1632ff7e8e068b7e6a1c107de0eb748c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
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?
>>> 
>>> 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]]

Also I came across this when I accidentally annexed some files in the .git-annex directory and it cause git-annex/git to be very unhappy when i pulled the repo to somewhere else. It might be worth teaching git-annex to disallow annex'ing of files inside the .git-annex/.git directories.

> There is a guard against `git annex add .git-annex/foo`, but it doesn't
> notice `cd .git-annex; git annex add foo`. --[[Joey]]