Comments in the moderation queue:
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
And on the clone (after some copying, moving, dropping and sync)
C:\Users\me\q\ga>git annex list
And, of course, thanks for the fix.
Thanks for testing. I see I had a problem with my fix; have improved it and
the windows build is updated.
Sorry, my bad.
Just installed this build: https://qa.nest-initiative.org/view/msysGit/job/msysgit-git-annex-assistant-test/4837/
Still getting the error. %GIT_SSH% is not set.
C:\Users\me\q\ga>git annex sync
Invalid argument `email@example.com'
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
N256 SKEIN512 MD5 WORM URL
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
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,
git annex sync --content does what you want, only it also does a pull and
a merge from remotes.
git annex sync --content
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.
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..
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
Windows build didn't actually get updated until now.
And only the autobuild is updated, not the last release build of course.
I did a quick test just after seeing the last comment using the build from here: https://downloads.kitenet.net/git-annex/autobuild/windows/ 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
Invalid argument `firstname.lastname@example.org'
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