code:
### Please describe the problem.

I have a annex repo in external drive (a bare repo), usually synced with a macbook. When I'm trying to sync the drive over to a Windows machine, all contents fail to sync over. I managed to reproduce the problem with a set of instructions locally:

    C:\Temp\test>dir
     Volume in drive C is Windows
     Volume Serial Number is 6839-6E71

     Directory of C:\Temp\test

    2014/05/08  23:08    <DIR>          .
    2014/05/08  23:08    <DIR>          ..
    2014/05/08  23:08                14 file.txt
                   1 File(s)             14 bytes
                   2 Dir(s)  164,943,056,896 bytes free

    C:\Temp\test>git init
    Initialized empty Git repository in C:/Temp/test/.git/

    C:\Temp\test>git annex init
    init
      Detected a filesystem without fifo support.

      Disabling ssh connection caching.

      Detected a crippled filesystem.

      Enabling direct mode.
    ok
    (Recording state in git...)

    C:\Temp\test>git annex add .
    add file.txt ok
    (Recording state in git...)

    C:\Temp\test>cd ..

    C:\Temp>mkdir bare

    C:\Temp>cd bare

    C:\Temp\bare>git init --bare
    Initialized empty Git repository in C:/Temp/bare/
    C:\Temp\bare>git annex init
    init
      Detected a filesystem without fifo support.

      Disabling ssh connection caching.

      Detected a crippled filesystem.
    ok
    (Recording state in git...)

    C:\Temp\bare>cd ../test

    C:\Temp\test>git remote add mybare C:\Temp\bare

    C:\Temp\test>git annex sync --content mybare
    commit  ok
    pull mybare
    warning: no common commits
    remote: Counting objects: 5, done.
    remote: Compressing objects: 100% (3/3), done.
    remote: Total 5 (delta 0), reused 0 (delta 0)
    Unpacking objects: 100% (5/5), done.
    From C:\Temp\bare
     * [new branch]      git-annex  -> mybare/git-annex
    ok
    (merging mybare/git-annex into git-annex...)
    (Recording state in git...)
    copy file.txt copy file.txt (to mybare...)
    file.txt
              14 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/1)

    sent 86 bytes  received 31 bytes  234.00 bytes/sec
    total size is 14  speedup is 0.12
    ok
    pull mybare
    ok
    (Recording state in git...)
    push mybare
    Counting objects: 23, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (16/16), done.
    Writing objects: 100% (21/21), 1.94 KiB | 0 bytes/s, done.
    Total 21 (delta 1), reused 0 (delta 0)
    To C:\Temp\bare
     * [new branch]      git-annex -> synced/git-annex
     * [new branch]      annex/direct/master -> synced/master
    ok

    C:\Temp\test>cd ..

    C:\Temp>git clone C:\Temp\bare test2
    Cloning into 'test2'...
    done.

    C:\Temp>cd test2

    C:\Temp\test2>ls -l
    total 1
    ----------+ 1 Ruo None 188 May  8 23:10 file.txt

    C:\Temp\test2>git annex init
    init
      Detected a filesystem without fifo support.

      Disabling ssh connection caching.

      Detected a crippled filesystem.

      Enabling direct mode.
    ok
    (Recording state in git...)

    C:\Temp\test2>git annex get file.txt
    get file.txt (merging origin/git-annex origin/synced/git-annex into git-annex...)
    (Recording state in git...)

      Unable to access these remotes: origin

      Try making some of these repositories available:
            f2af6f52-18d5-4a54-ae5c-c4bef5fab00c -- origin (MY-PC:C:\Temp\bare)
            fc00306a-157c-439b-a5c3-37aabf9d61fb -- MY-PC:C:\Temp\test
    failed
    git-annex: get: 1 failed

    C:\Temp\test2>git version
    git version 1.9.2.msysgit.0

    C:\Temp\test2>git annex version
    git-annex version: 5.20140421-g78d6aa1
    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external
    local repository version: 5
    supported repository version: 5
    upgrade supported from repository versions: 2 3 4

[[!tag confirmed]]

> [[fixed|done]] --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="108.236.230.124"
 subject="comment 1"
 date="2014-06-05T17:37:08Z"
 content="""
I've reproduced this.

More simply: git annex move --to mybare and then git annex get will fail
"""]]

repo_name: kakafarm/git

license: unknown


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="108.236.230.124"
 subject="comment 2"
 date="2014-06-05T18:29:15Z"
 content="""
Appears to be a corrupt uuid log issue. At least, the bug I am seeing is. When retriving the uuid of the remote that has the key from the location log, it seems to get a uuid with one or more \r appended to it. Which smells of windows.

However, the bug I am seeing makes `git annex get` print out the uuids of the remotes without the description it normally shows (because these are not really the same uuids due to the \r). In the example above, this is not the case; the description is shown. I don't understand that.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="108.236.230.124"
 subject="comment 3"
 date="2014-06-05T19:06:36Z"
 content="""
The bug I was seeing with the \r was a recent reversion caused by [[!commit 95ca3bb02215744f3dbcaebd48844e1909c577f3]]. So, not related to original bug report. (And fixed now!)

I can now reproduce the original bug, including seeing the description of the bare repo when it says it cannot get the file from it.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="108.236.230.124"
 subject="comment 4"
 date="2014-06-05T19:20:20Z"
 content="""
Analysis: inAnnexSafe on Windows simply does not have indirect mode checking enabled. Bare repositories use indirect mode (essentially; same storage). So it fails.
"""]]


code:
### Please describe the problem.
While attempting to create a remote repository, the assistant is trying to set up public key authentication, but fails when trying to delete the temporary files. Perhaps this doesn't need to be a fatal error; it could warn the user instead, or try again later.

DeleteFile "C:\\Users\\FAMILY~1\\AppData\\Local\\Temp\\git-annex-keygen.1\\key.pub": permission denied (The process cannot access the file because it is being used by another process.)

### What steps will reproduce the problem?
Create a remote repository

### What version of git-annex are you using? On what operating system?
Windows 7, git-annex version 5.20131221-gf8c928d

> [[fixed|done]].. thanks for testing the assistant on windows! --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.152.246.110"
 subject="comment 1"
 date="2013-07-26T21:08:02Z"
 content="""
Tried to reproduce this, following your instructions. It did not seem to work:

<pre>
joey@gnu:~/tmp/mydir2>git annex get disk2
get disk2
  Unable to access these remotes: origin

  Try making some of these repositories available:
  	21606444-98f9-4c40-aa60-3ebfba936758 -- origin (joey@gnu:~/tmp/mydir)
failed
git-annex: get: 1 failed
- exit 1
joey@gnu:~/tmp/mydir2>git annex whereis disk2
whereis disk2 (1 copy)
  	21606444-98f9-4c40-aa60-3ebfba936758 -- origin (joey@gnu:~/tmp/mydir)
ok
joey@gnu:~/tmp/mydir2>
</pre>

So, not a silent failure. It is a little unclear about why it can't get the file (in this case because I moved .git/annex/objects out of the way), but it's pretty clear it can't.

AFAIK, the only way `git annex get` can silently not do anything is if you already have the file locally. Perhaps you got confused? OTOH, if you can provide a better way to reproduce this, I'm curious to see it.
"""]]


code:
[[!comment format=mdwn
 username="http://edheil.wordpress.com/"
 ip="99.54.57.201"
 subject="comment 2"
 date="2013-07-27T06:03:55Z"
 content="""
I actually ran through the test I described to you and got the silent failure, but now I'm doing it again and getting the \"Try making some of these repositories available\" error.  (Along with inaccurate \"whereis\" info, as you're seeing there.)  I'm baffled.  Unless something changed with respect to this behavior in the most recent version, which I've installed since then, I don't know what I was doing differently.  Maybe I was confused.

I can guarantee that I was getting silent failures in \"gets\" from my USB drive.  I was \"getting\" \"--from\" my USB drive, nothing was showing up (the symlink was broken), and no error was printed to the console, including the \"try making it available\" one we're getting now.  It's only when I went to the drive and did a \"git annex fsck\" that I realized that those files were actually missing from that remote, and it wasn't just a failure to \"get\" them.  The behavior was alarming enough that I made sure of what was happening before I made the bug report.  I wish I'd actually cut and pasted the demo, instead of just describing it!

It'd still be nice to have some kind of feedback in the assistant (and maybe more understandable feedback in the command line) that something was amiss.  What I would see in the assistant, because of this, is a bunch of queued downloads from the USB drive, but as each one was ready to execute, it would disappear (because it failed) and be replaced by a download from the (lower priority) SSH repo.  This happened a number of times and I found it baffling.

My first instinct in a situation like this is to say \"yeah, I must have been confused\" but I honestly did check this out pretty carefully before sending it in, so I wonder if a recent update improved matters, perhaps inadvertently?  In any case, I'm glad there's some kind of error right now.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.152.246.110"
 subject="comment 3"
 date="2013-07-27T22:39:12Z"
 content="""
The --from is the missing piece to reproduce:

[[!format sh \"\"\"
joey@gnu:~/tmp/old/mydir2>git annex get disk2 --from origin
joey@gnu:~/tmp/old/mydir2>
\"\"\"]]

What's going on here is that `get --from` is essentially an alias to `copy --from`, and that skips copying files that it knows are not present on the remote. Since the remote is a local directory, it's inexpensive for it to check if the file is really there, rather than relying on the location log.

This seems suboptimal, but I'm not sure which part of the behavior it makes sense to change. It seems nice for `copy --from` to silently skip files that the remote does not have, to avoid much unnecessary output when processing a lot of files. Maybe `get --from` should behave differently?
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.152.246.110"
 subject="comment 4"
 date="2013-07-27T22:40:58Z"
 content="""
I should add that it also seems to make sense to stat the file to see if it's present, like it does now. The location log can be out of date, and when more accurate info is right there, it should use it. And nor is the location log being out of date something that it should complain about, because it can easily happen eg when `git annex sync` has not been run recently.
"""]]


code:
[[!comment format=mdwn
 username="http://edheil.wordpress.com/"
 ip="99.54.57.201"
 subject="comment 5"
 date="2013-07-28T05:29:00Z"
 content="""
Oh yeah!  That makes sense now.  It's not exactly that it's failing, it's just that the command \"git annex get --from=bar foo\" means \"get any copies of foo which might exist in the bar remote.\"  Not \"get the copy of foo which I happen to know exists in the bar remote.\"

I'm not sure either exactly what \"better\" behavior would be.
"""]]


code:
### Please describe the problem.
In a usb drive with a repository in direct mode, when I converted to indirect mode it fails

### What steps will reproduce the problem?
cd /Volumes/usb
git annex indirect

### What version of git-annex are you using? On what operating system?
git-annex version: 4.20130627

### Please provide any additional information below.

[[!format sh """
openFile: resource busy (file is locked)
failed
git-annex: indirect: 1 failed
"""]]

[[!tag moreinfo]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.154.4.193"
 subject="comment 1"
 date="2013-07-02T16:38:14Z"
 content="""
What filesystem is in use on this USB drive? For example, is it a FAT filesystem?

What operating system are you using?
"""]]


code:
Klaus pointed out that there are two problems that keep
git-annex from being used on USB keys, that would typically
be VFAT formatted:

- Use of symlinks, which VFAT does not support. Very hard to fix.
  Instead, just use [[/bare_repositories]] on the key,
  they're supported now.
- Use of ":" in filenames of object files, also not supported.
  Could easily be fixed by reorganizing the object directory.

[[Done]]; in annex.version 2 repos, colons are entirely avoided in
filenames. So a bare git clone can be put on VFAT, and git-annex
used to move stuff --to and --from it, for sneakernet.


code:
[[!comment format=mdwn
 username="fmarier"
 ip="121.73.248.43"
 subject="Exporting to a FAT filesystem?"
 date="2011-04-04T07:40:41Z"
 content="""
I'm using git-annex to keep my music in sync between all of my different machines. What I'd love to be able to do is to also keep it in sync with my iRiver player. Unfortunately, the firmware, Rockbox, doesn't support ext3, so I'm stuck with a FAT filesystem.

I can see how the design of git-annex makes it rather difficult to get rid of the symlinks, so how about taking a different approach: something like a \"git annex export DEST\" which would take a destination (not a git remote) and rsync the content over to there as regular files.

Maybe \"git annex sync DEST\" or \"git annex rsync DEST\" would be better names if we want to convey the idea that the destination will be made to look like the source repo, including performing the necessary deletions.
"""]]


code:
[[!comment format=mdwn
 username="http://joey.kitenet.net/"
 nickname="joey"
 subject="comment 2"
 date="2011-04-04T18:20:45Z"
 content="""
Hey @fmarier. Well, this bug report is closed because you can already get rid of the symlinks. Just put a bare git repo on your fat filesystem, and use git-annex copy --to/--from there.

Now, that puts all the files that are on the device in .git/annex/objects/xx/yy/blah.mp3 -- how well rockbox would support that I don't know. And if it tries to modify or delete those files, git annex also can't help you manage those changes.

Another recent option is the [[special_remotes/directory]] special remote type, which again uses \"xx/yy/blah.mp3\" and can't track changes made to the files. This could perhaps be extended in the direction you suggest, although trying to fit this into the special remote infrastructure might not be a good fit really.

The most likely way this has to get dealt with is really by using [[todo/smudge]] filters, which would eliminate the symlinks and allow copying a non-bare git repo onto vfat.
"""]]


code:
[[!comment format=mdwn
 username="fmarier"
 subject="comment 3"
 date="2011-04-05T10:00:21Z"
 content="""
Thanks for the reply @joey.

While it would certainly be possible for a bare repo to exist on my iRiver, the problem is that the music player uses the filesystem to organize files into directories like \"Artist/Album/Track.ogg\". So replacing that with \"..../xx/yy/Track.ogg\" would make it fairly difficult to browse my music collection and select the album/track I want to listen to :)

So unless I have the files physically organized like the symlinks, then it's probably not going to work very for that particular workflow. Smudge filters are interesting though. In the meantime, I'll look into rsyncing from another box which has the right filesystem layout onto my iRiver directly.
"""]]


code:
[[!comment format=mdwn
 username="http://ethan.betacantrips.com/"
 nickname="ethan.glasser.camp"
 subject="no symlinks"
 date="2011-06-08T20:59:38Z"
 content="""
If you try to clone a git repo that has a symlink over to a VFAT filesystem, you get (in its place) a regular file that contains the name of the symlink target.  So why can't git-annex use that?  I could still do git annex get on this file, git annex would still \"know\" that it's a symlink, and could replace it with a copy of the real file (instead of putting it in .git/annex).

I know if it were that simple, someone would have done it already, so what am I missing?  I guess trying to get the file FROM the repository would fail because it wouldn't find the file in .git/annex?  Couldn't you store a reverse mapping?  You wouldn't be able to move the file around, but you already lose that once you give up symlinks.  It would also be a little harder to tell which symlinks were \"dangling\"; I don't see an easy way to get around that.  It would still be better than a bare repo..
"""]]


code:
[[!comment format=mdwn
 username="http://joey.kitenet.net/"
 nickname="joey"
 subject="comment 5"
 date="2011-06-10T16:41:43Z"
 content="""
@ethan the reason that wouldn't work is because git would then see a file that was checked in and had its one line symlinkish content replaced with a huge binary blob. And git commit would try to commit that etc. The potential for foot-shooting is too high.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawkZRoTRyW3tox-FD2DQWxskgI6_tkEtHL4"
 nickname="Ben"
 subject="comment 6"
 date="2012-07-23T16:11:52Z"
 content="""
The above would work fine for me but the files in my annex (e.g. .git/annex/objects/xx/yy/blah.ogg) don't have extensions like that, so my media player doesn't recognize them as media files. How do I get the files under \"objects\" to keep the extensions of the original files like in Joey's example?
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 subject="comment 7"
 date="2012-07-24T14:51:50Z"
 content="""
You can get the extensions by migrating to the SHA1E (or SHA256E) backend.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmcYryijvlF8bJvM_eZNSrUPEkMlxMDGTQ"
 nickname="Thiago"
 subject="POSIX layer on top of VFAT using FUSE"
 date="2012-11-24T00:21:23Z"
 content="""
I just found out about this project and didn't try it, but it looks like it would allow using git-annex on an usb stick with a normal repository:

<http://sourceforge.net/projects/posixovl/>
"""]]


code:
### Please describe the problem.
Not able to successfully git-annex sync with a remote due to a git fatal. Caused by masters diverging?

### What steps will reproduce the problem?
git-annex sync, or, letting the assistant try.

### What version of git-annex are you using? On what operating system?
git-annex version: 5.20131221+b1 on my laptop
git-annex version: 5.20131224-g6ca5271 on the remote server

### Please provide any additional information below.

Output of a manual git-annex sync in the directory:

[[!format sh """
greg@x200s:~/Documents$ git-annex sync
commit  (Recording state in git...)
Copyright Office/Orphan Works/ARROW/170409_ARROW_Leaflet.pdf: unmerged (783afced6bc43138373fda43edfda0c33be36525)
Copyright Office/Orphan Works/ARROW/ARROWproject_results1.pdf: unmerged (b536e5f3d93e7905e05510f26db1f743e9eae16e)
Copyright Office/Orphan Works/ARROW/ARROWproject_results1.ppt: unmerged (5543049b8940cc5702d37aff18b03c67d9c8374d)
Copyright Office/Orphan Works/ARROW/ARROWstandardPresent2010.pdf: unmerged (54d751bc98cb5da29d3d568856b74675e842072e)
Copyright Office/Orphan Works/ARROW/ARROWstandardPresent2010.ppt: unmerged (efe0e94b51eccb9a6a0c352f4a210bd5a6105050)
Copyright Office/Orphan Works/ARROW/ARROWtrifoldMAR2011.pdf: unmerged (b52ff16178e29261fe00a518c23610a3b0826482)
Copyright Office/Orphan Works/Documentation/20110531/Documentation.doc.odt: unmerged (1348d5f42f7e34706407f7936f4fb0438e4b8ffa)
Copyright Office/Orphan Works/Documentation/AAPpublishers.pdf: unmerged (3f448a03d31a38adb095e3031e4ee13771d22d70)
Copyright Office/Orphan Works/Documentation/Documentation.doc: unmerged (265fdff7787f560e3ba20789a12e15ffb165ec7f)
Copyright Office/Orphan Works/Documentation/Documentation.pdf: unmerged (7a9ff92663ed42b42b9baaefaf4721499d18d82d)
...
fatal: git-write-tree: error building trees
git-annex: failed to read sha from git write-tree
"""]]

See also:

1. the [partial daemon log](http://paste.debian.net/73176/) from the assistant running in that directory on the laptop and
2. the output of [git fsck](http://paste.debian.net/73175/) on the remote.

git-annex repair on the laptop and the server:
[[!format sh """
greg@x200s:~/Documents$ git-annex repair
Running git fsck ...
No problems found.
ok
"""]]

### How I ended up fixing it:
[[!format sh """
greg@x200s:~/Documents$ killall git-annex
greg@x200s:~/Documents$ git-annex indirect
blah...............
indirect  ok
ok
greg@x200s:~/Documents$ git status
On branch master
Your branch and 'rose/master' have diverged,
and have 294 and 1 different commit each, respectively.
  (use "git pull" to merge the remote branch into yours)

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	.gitrefs/

nothing added to commit but untracked files present (use "git add" to track)
greg@x200s:~/Documents$ git pull
Merge made by the 'recursive' strategy.
 Copyright Office/Orphan Works/staging/reporting/process_report.txt.2 | 1 +
 Copyright Office/Orphan Works/staging/reporting/with-title.xls       | 1 +
 Copyright Office/Orphan Works/staging/with-title.xls                 | 1 +
 Copyright Office/Orphan Works/worker_emails.txt                      | 1 +
 git.fsck.log                                                         | 1 +
 5 files changed, 5 insertions(+)
 create mode 120000 Copyright Office/Orphan Works/staging/reporting/process_report.txt.2
 create mode 120000 Copyright Office/Orphan Works/staging/reporting/with-title.xls
 create mode 120000 Copyright Office/Orphan Works/staging/with-title.xls
 create mode 120000 Copyright Office/Orphan Works/worker_emails.txt
 create mode 120000 git.fsck.log
greg@x200s:~/Documents$ git-annex sync
commit  ok
pull rose

Already up-to-date.
ok
push rose
Counting objects: 1658, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (904/904), done.
Writing objects: 100% (1604/1604), 138.97 KiB | 0 bytes/s, done.
Total 1604 (delta 892), reused 1298 (delta 688)
To greg@rose.makesad.us:/home/greg/Documents/
   f1d206e..e836b9b  master -> synced/master
ok
greg@x200s:~/Documents$
"""]]

I restarted the assistant and the daemon.log looks good.

After sync'ing on the server, it appears that this has been the case for quite some time (based off of what symlinks were created).

Lastly: Joey, this is probably what caused that weird behavior in the webapp where it showed the bad transfer each day after the fsck at noon. I never diagnosed that more but I bet I won't see it tomorrow.

[[!tag moreinfo]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.35"
 subject="comment 2"
 date="2014-01-06T16:14:29Z"
 content="""
As far as I can tell from git's code, this involves a \"cache-tree\" data structure stored in git's index file. git-annex has nothing to do with writing index files, beyond running git plumbing. So I don't see how this could be anything other than a corrupt index file (of a sort that git fsck doesn't detect), or a git bug. The best thing to do would be to send an example of a repository having this problem to the git developers for analysis.
"""]]


code:
### What steps will reproduce the problem?
[[!format sh """
C:\Users\Bruno>mkdir annex

C:\Users\Bruno>cd annex

C:\Users\Bruno\annex>git init
Initialized empty Git repository in C:/Users/Bruno/annex/.git/

C:\Users\Bruno\annex>git annex init
init
  Detected a crippled filesystem.

  Enabling direct mode.

  Detected a filesystem without fifo support.

  Disabling ssh connection caching.
ok
(Recording state in git...)

C:\Users\Bruno\annex>echo test > test

C:\Users\Bruno\annex>git annex add .
add test (checksum...) ok
(Recording state in git...)

C:\Users\Bruno\annex>git commit -a -m added
[master (root-commit) 2eea610] added
 1 file changed, 1 insertion(+)
 create mode 120000 test

C:\Users\Bruno\annex>git annex sync
(Recording state in git...)
fatal: unable to access '../../../../C:\Users\Bruno\annex\.git/config': Invalid argument

git-annex: user error (xargs ["-0","git","--git-dir=C:\\Users\\Bruno\\annex\\.git","--work-tree=C:\\Users\\Bruno\\annex","add","-f"] exited 123)
failed
git-annex: sync: 1 failed
"""]]

### What version of git-annex are you using? On what operating system?
Windows 8 (64 bits)

git version 1.8.4.msysgit.0

[[!format sh """
git-annex version: 4.20131008-ge115441
build flags: Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
remote types: git gcrypt S3 bup directory rsync web webdav glacier hook
local repository version: 4
default repository version: 3
supported repository versions: 3 4
upgrade supported from repository versions: 2
"""]]

### Please provide any additional information below.
C:\Users\Bruno\annex\.git\config exists

> xargs was one problem; also msysgit seems to just not
> accept DOS style paths anymore in --git-dir or --git-work-tree.
> megaweird. [[fixed|done]] --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="64.134.31.139"
 subject="comment 1"
 date="2013-10-16T20:42:07Z"
 content="""
I don't know what to make of this bug report. You say that \"C:\Users\Bruno\annex.git\config\" exists, but you show the creation of a \"C:\Users\Bruno\annex\", and not the other repository. I cannot reproduce it, even if I first \"git init --bare annex.git\".
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawkGCmVc5qIJaQQgG82Hc5zzBdAVdhe2JEM"
 nickname="Bruno"
 subject="comment 2"
 date="2013-10-16T22:47:46Z"
 content="""
There's no other repo yet. I have the same problem when I try to sync between two repos but I simplified the instructions to reproduce the bug easily.

Here's the instructions on Debian :
[[!format sh \"\"\"
bruno@debian:~$ mkdir annex
bruno@debian:~$ cd annex
bruno@debian:~/annex$ git init
Initialized empty Dépôt git dans /home/bruno/annex/.git/
bruno@debian:~/annex$ git annex init
init  ok
(Recording state in git...)
bruno@debian:~/annex$ echo test > test
bruno@debian:~/annex$ git annex add .
add test (checksum...) ok
(Recording state in git...)
bruno@debian:~/annex$ git commit -a -m added
[master (root-commit) 631049d] added
 1 file changed, 1 insertion(+)
 create mode 120000 test
bruno@debian:~/annex$ git annex sync
commit
ok
bruno@debian:~/annex$\"\"\"]]

It seems --git-dir wants 'c:/...' instead of 'c:\\...'.

[[!format sh \"\"\"
C:\Users\Bruno\annex>git --git-dir=C:\\Users\\Bruno\\annex\\.git --work-tree=C:\\Users\\Bruno\\annex add -f test
fatal: unable to access '../../../../C:\\Users\\Bruno\\annex\\.git/config': Invalid argument

C:\Users\Bruno\annex>git --git-dir=C:/Users/Bruno/annex/.git --work-tree=C:\\Users\\Bruno\\annex add -f test

C:\Users\Bruno\annex>\"\"\"]]

It's weird that I don't have any problem with the following command:
[[!format sh \"\"\"C:\Users\Bruno\annex>git --git-dir=C:\\Users\\Bruno\\annex\\.git --work-tree=C:\\Users\\Bruno\\annex config -l
core.symlinks=false
core.autocrlf=true
[...]\"\"\"]]

Maybe there's a problem with `git version 1.8.4.msysgit.0`.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="108.236.230.124"
 subject="comment 4"
 date="2013-10-17T21:49:10Z"
 content="""
So this is a problem with msysgit 1.8.4. I have been able to reproduce it with that version. 1.8.3 did not have the problem.

Seems to perhaps be due to the cygwin xargs flipping git into cygwin path mode somehow. (How all this works is massively complex and confusing to me.)
All the other calls to git with identical parameters work fine. I can also reproduce the problem using some old git 1.7.x in the cygwin terminal.

BTW, I noticed in your example that you ran \"git commit -a\". You should **never** do that in a [[direct mode]] repository. Read the direct mode documentation to understand why.
"""]]