I just tried in the browser console, and see the same behaviour.

I also see that links work when not on the dashboard.

I disabled javasript (set javascript.enabled to false in about:config), and the links all work well (though dropdown menus don't work at all).

(I see after writing this you seem to have worked it out already)

Tried renaming / to /dashboard , just in case firefox was having problems with the name of the page. Didn't help, so the problem must be something on the page.

Tried removing the repolist and the transferlist from the dashboard, and this indeed avoided the problem. So it's certainly related to the long polling code. Although note that this left 1 long polling call still on the page, for the sidebar. In fact, only removing one of the repolist or transfer list seems to be enough to avoid the problem. 1 works, 2 works, 3 fails.

Aha.. After 3 long polling failures, the JS runs a fail function. To work around a seeming bug in chromium when navigating back to a page, b5678d74a29023cbeb3d65c0d7f57d20f47ebef9 made this reload the page.

Thanks, that's very interesting indeed.

When I was debugging this on Windows, I had the network console open, and could see clearly that Firefox was trying to load "/" when I clicked on a link to "/config". Both firefox and the git-annex webapp's debug log agreed that it asked for the wrong page.

I have just reproduced it using iceweasel as well. I know that I have tested git-annex before under iceweasel and it seemed to work.

Seems that clicking 3+ times on a link makes it finally follow it.

I wonder if this has something to do with the long polling. Disabling javascript would avoid it if so. They've made disabling JS in firefox sufficiently hard that I cannot find how to do it.

Also, the problem seems to open happen on the main page (/). Once I get to any other page, further links are followed without trouble.

Yeah! Looking forward to finally introduce git-annex in my heterogeneous network. Thanks and keep up the good work!

It [1] allows you to run commands on a set of repositories.

[1] http://myrepos.branchable.com/

Hi there,

I try to follow the instructions provided here but I don't manage it to get my repo encrypted. Here are the steps:

1) git init --bare Encrypted 2) git-annex init 3) git annex initremote encryptedbackup type=gcrypt gitrepo=~/tmp/Encrypted encryption=pubkey keyid=DXXXX

The last step takes a lof of time to run. Basically my key doesn't get used at all:

# ps -ax | grep gpg
4743 pts/4    SL+    0:00 gpg --quiet --trust-model always --gen-random --armor 2 256
4753 pts/0    S+     0:00 grep gpg

... instead a new pgp key is generated. How comes??!

Any help would be appreciated.

Thx and cheers,

cyneox

what is 'mr'?

I do track my home dir using annex, but instead of one giant annex I have multiple annex repos. It is much faster than one giant annex and when used in combination with mr you can threat all repos as one.

The above scenario is also quite interesting to me. Similarly running and old OS (Debian 4.x) on a NAS, and it would be great to be able to access files directly (via direct mode) and manage via git annex, along with a true backup elsewhere. Mostly commenting so I'll get emails for further discussion here.

Same use case here. Hey, I even also use ~/work.

I've burned my fingers on git repositories synched via Dropbox, so I share the reservations against it. But in my case the trouble came from lack of caution when sharing the given Dropbox folders. I'm not sure what the risks are when I'm in control of all the copies. Synching between my own computers should not pose a problem, I know how to create branches for experimental stuff etc.

I'd love to use git-annex is to maintain dispersed repositories while synching and archiving effectively. The issue with .git directories is a real blocker and I'd really appreciate a workable solution. It doesn't have to be perfect, but manually invoking submodule or the need to configure lots of remotes is not exactly practical.

I don't know enough to fully understand everything above. So what follows may be hopelessly naive. But it occurred to me there may be a simpler solution: what if git-annex changed the name of its repo to .annex (or so) instead of .git? And maybe similarly .gitignore to .annexignore etc. Wouldn't the nested git repositories then "just work"? Because of the hardcoded ignore rules, this approach would require a tweaked git for annex... but overall, wouldn't it be cleaner and more minimal?

I'm probably overlooking something, but maybe this idea can lead somewhere?