In regular repos, objects are stored in files of the form: .git/annex/objects/xY/z1/SHA1-.../SHA1-.... (scheme 1)
On (some) special remotes, the corresponding file is stored at: .../abc/def/SHA1-... (scheme 2)
I'm not sure why the same scheme as in .git/objects isn't used, but it would be useful that the two-directory prefix were the same for all objects stores.
My use case is: I synchronize a git repo, say containing photos, to a server on which I can't install git-annex. I want the server to store all annexed files. For the photos to be viewed online, the annex store must use the scheme 1 (because the symlinks point to files with scheme 1). So I need to rsync .git/annex/objects manually from my desktop, because a git-annex rsync remote uses scheme 2. On the other hand, the repo on this server is not known by git-annex (like it would if I used a rsync remote).
At least it would be valuable (to get around above problem) to have a plumbing command giving the 2-directory prefix from a given key, for example:
$ git annex prefix-dir SHA1-s2--3f786850e387550fdab836ed7e6dc881
7w/88
f18/122
Even if the 2 schemes were unified, this prefix-dir command would still be useful when hacking around git-annex (for now I need to maintain a dictionary structure).
Thanks a lot.
Using the mixed case hash directory names is not desirable because people want to use git-annex on a variety of filesystems and operating systems that treat them in a variety of broken ways. However, migrating to the all lower case hash directory names would require changing every git-annex symlink in every git repository, and I do not want to inflict that on my users.
It seems to me that the best solution to your problem is to install git-annex on your server, which should not be very hard.
Thank you for prompt answer. I didn't know there were tarballs, and indeed I managed to install them easily (although I had to manually install glibc version 2.9, only 2.7 was installed).
I found that bare git repos also use lower case hash directory names... I still would be happy with an optional migration to all lower case, with a new key-value backend, to avoid this little complication which happens sometimes (say when converting a repo from non-bare to bare).