Recent comments posted to this site:

thank you. I workaround this by using the DNS hostname instead the IPv6 address directly. But this is not a nice solution, like any workaround. But now i have problems with git annex get over IPv6-only:

get ***.mp3 (not available) Try making some of these repositories available: 5636aefa-c509-4ea0-bebe-f5b96d8eb15a -- hserver failed <snip>

but i can ping it: thomas@alus:~/Musik$ ping6 hserver.h.b128.net PING hserver.h.b128.net(fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e) 56 data bytes 64 bytes from fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e: icmp_seq=1 ttl=42 time=453 ms 64 bytes from fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e: icmp_seq=2 ttl=42 time=441 ms 64 bytes from fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e: icmp_seq=3 ttl=42 time=425 ms 64 bytes from fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e: icmp_seq=5 ttl=42 time=413 ms (the high pings are caused by a download from an other source. Also i have no problems with rsync over IPv6)

PS: the markdown for code blocks is not working too :)

Comment by Torkaly Mon Sep 1 11:01:30 2014
Occurs to me that your repo may not have a pre-commit hook; if not then git commit -a would not behave as I described..
Comment by joeyh.name Sun Aug 31 22:29:44 2014

I have found out that there is a connection between this problem and the global configuration of annex.alwayscommit. This problem will appear only if annex.alwayscommit is globally set to false. What is very strange is that setting annex.alwayscommit locally does not make this bug appear; only a globally set annex.alwayscommit will trigger this problem.

I fixed the test script to set annex.alwayscommit globally.

Now I see why I could reproduce this bug on different machines but Joey could not: all my machines have the same ~/.gitconfig.

Comment by gioele Sun Aug 31 10:15:30 2014
number of copies is the minimum number of copies that can exist when you try to drop a file from a repository/without git-annex telling you that you don't have enough copies and should protect your data better. A full backup by default tries to get every file it can get its hands on, including old versions.
Comment by Efraim Sun Aug 31 07:09:52 2014

Try using ~/.ssh/config as a workaround

Host myserver
Hostname fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e

then just tell git-annex to use myserver

Comment by Justin Thu Aug 28 20:46:29 2014

My version is:

assistant version 5.20140517.4

Comment by anders7788 Wed Aug 27 06:59:08 2014

I decided it was a bit harsh, so I removed comment. Here is how I solved problem:

I have a server without much storage which runs the git-annex process, the data is stored on the NAS mounted via iSCSI. I never even thought of trying to compile git-annex on a NAS. I did things like that many years ago and it used to much time, whether the language was, common or not, didn't change much. Missing floating point units on the NAS killed performance of the programms I wanted to run anyways.

Comment by Ganwell Tue Aug 26 23:03:09 2014
To add to my comment I also installed git-annex in the same directory as the msys git distrib in both cases.
Comment by y Tue Aug 26 12:18:39 2014

Unlike under POSIX environments generally applications under windows don't add themselves to path, or to a directory already in path.

Generally applications announce their location using the registry. Under either HKEY_LOCAL_MACHINE\SOFTWARE, or in case of software installed for one particular user only under HKEY_CURRENT_USER\SOFTWARE.

Git however AFAIK does not. Most likely the best thing to do is to prompt the user when installing git-annex where git is, and store this variable.

Note that in both my installs I installed git-annex into the git directory, and the git-annex webapp still couldn't find it.

Comment by Hans_Ryding Mon Aug 25 16:16:33 2014

Imagine a rather contrived doomsday scenario: the file paths and/or basenames are important and, for some reason, the symlinks are not present (perhaps they got deleted, or aren't supported). git and git-annex no longer exist and let's assume knowledge of git internals is not useful here. All the content is there, stored under hashed file names under .git/annex/objects.

I may be missing something obvious but I think options for restoring file paths include:

  • direct mode bypasses this issue; all the files are right there.
  • the WORM backend perhaps carries enough information in the object file names to work with.
  • file content/metadata may be sufficient to easily recreate a sensible directory structure in some cases, so no worries.

These first two options may represent compromises in various use-cases and the last may not be applicable or, if it is, practical. The object-path mapping could trivially be backed up in plain text in lieu of these. Like I said, I may be overlooking something here that makes this unnecessary or even a non-concern (actually, I've convinced myself it's not a serious concern in most of the use-cases I've considered, but crossing i's and dotting t's).

Comment by electrichead Mon Aug 25 15:51:00 2014