Recent comments posted to this site:

Installed build 4839 and everything seems to work. One quick question though, doing sync on an origin and clone repos, shouldn't it make the git annex list look the same on both? I'm getting on the remote

me@mint64vm ~/ga $ git annex list
X_ me
X_ me_local
X_ me_origin

And on the clone (after some copying, moving, dropping and sync)

C:\Users\me\q\ga>git annex list
_X__ me
_X__ me_local
_X__ me_origin

And, of course, thanks for the fix.

Comment by threadshuffle Tue Aug 4 21:46:17 2015

Thanks for testing. I see I had a problem with my fix; have improved it and the windows build is updated.

Comment by joey Tue Aug 4 20:54:23 2015

Sorry, my bad.
Just installed this build:
Still getting the error. %GIT_SSH% is not set.

C:\Users\me\q\ga>git annex sync
commit  ok
pull origin
Invalid argument `me@'
C:\Users\me\q\ga>git annex version
git-annex version: 5.20150804-g4b8b3c6
build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA TorrentParser Database
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEI
remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
local repository version: 5
supported repository version: 5
upgrade supported from repository versions: 2 3 4
Comment by threadshuffle Tue Aug 4 20:49:34 2015

Well, the file is not uploaded to the bitbucket remote, because bitbucket doesn't support git-annex. Without git-annex-shell on the remote, git-annex cannot send files to it.

Even if it did, it would need to be a ssh transport, not a http transport, since git-annex doesn't upload files over http (except to S3 or webdav remotes).

I think that the assistant also assumes that http transport git remotes are read-only, and doesn't try to push to them. Which might be improvable, perhaps.

Comment by joey Tue Aug 4 20:23:58 2015

git annex sync --content does what you want, only it also does a pull and a merge from remotes.

I don't know that wanting to only push, w/o pull and merge, is common enough to make a separate command for it.

There's also the problem that to push the git-annex branch, it really makes sense to first pull/merge from the remote. Otherwise, the push is not likely to work as well. And too, it makes sense to update the git-annex branch from remotes in order to know what files that have, so that info can be better used to decide which files to send to them -- especially when preferred content might make some file not be sent to all remotes, depending on which other remotes contain the file.

Comment by joey Tue Aug 4 20:19:22 2015

This is actually something that got worse when fsck changed to using a database, rather than its old sticky-bit based hack. Parallel fsck used to work entirely perfectly, they could even be run on the same directories w/o processing files redundantly.

Now, it's safe to run multiple fsck processes in parallel. However, since the database is only occasionally updated, if the two fscks are working on the same directory, one won't know that the other has already fscked a file, and they'll tend to do redundant work.

It'll work fine if you give concurrent fscks different directories or sets of files to work on. The git-annex key (ie, symlink target of a file) is the primary-key.

Also, I'd at some point like to make git-annex fsck -J work. With concurrent fsck jobs running in the same process, it could easily divide work up amoung them. The only tricky part is the output of the concurrent jobs would be scrambled and interleaved..

Comment by joey Tue Aug 4 20:14:00 2015

The assistant's automation for setting up a remote ssh server is what looks to be failing. It seems that this NAS has a problem with ssh being used to run a sh -c command. Probably the NAS's shell is not POSIX compliant in some way.

The best thing to do in this situation is to set up the git remote on the NAS manually. Once it's set up, the assistant should be able to use it.

Comment by joey Tue Aug 4 20:09:36 2015

Windows build didn't actually get updated until now.

And only the autobuild is updated, not the last release build of course.

Comment by joey Tue Aug 4 20:03:51 2015

I did a quick test just after seeing the last comment using the build from here: and it seems it's not working. I'll try the new git version as stated somewhere above later to see if that works. I'm still getting this (followed by the big help text)

C:\Users\me\gatest>git annex sync
commit  ok
pull origin
Invalid argument `me@'
Comment by threadshuffle Tue Aug 4 19:56:06 2015

Nice analysis.

I can't see any way to avoid this problem. So, seems like a "don't do that then" situation. And indeed, it makes sense to detect it and fail in a comprehansible way.

Comment by joey Tue Aug 4 19:34:34 2015