I'm trying to make git-annex work with the ipfs special remote here: (https://git-annex.branchable.com/special_remotes/ipfs/). Publishing to IPFS works, but I cannot retrieve the files onto another machine through git-annex
Running git-annex copy --to ipfs does copy files onto ipfs, I can access them through the CIDs (through an IPFS gateway like ipfs.io/ipfs/), and I can view the annexed files on running git annex whereis
But, git annex whereis on the other computer gives an empty output. (even after running git annex sync on both systems). git annex copy --from ipfs also gives no output on the other system.
Is there something obvious that I'm missing?
Yes I have a repository on Github. Starting with an empty repo, I clone it on both machines, then run all the git-annex commands (first enabling the remote, then adding the file, then copy to remote, then sync). Is this what you meant?
git-annex-syncwith the--contentflag?--contentflag. I thought that was for syncing content as well, rather than just the locations of files?Hmm, it should work as you described it. Did you run
git annex syncon the 2nd repo after runninggit annex syncon the 1st repo (where you copied the files to the ipfs remote)? Can you post the output of the following actions, in that order:You're right, sorry, I misread your post. For syncing just the location info
--contentis not needed.Here's a detailed sequence of what I'm doing: I made an empty repository on github. Then, on machine #1:
Then I clone the repository from github on machine #2:
To resolve this, I run git pull, then run sync again:
masterbranch on the 2nd repository withgit checkout master.That works! That completely slipped my mind.
Thanks a lot!
Hmm, github has found some way to break usual git operation here, by making the git-annex branch be the one that git checks out on clone.
I was able to reproduce that with the bare repository on github, the list of branches in their UI started with synced/git-annex, and cloning that repo resulted in that branch being checked out.
Compare with a bare repository on a regular ssh server, git clone picks master as the head branch, because the bare git repo has HEAD set to master. (That happens at init time, the init branch name is configurable now.)
Seems that github is assuming that the first branch pushed is the head branch. It may be that's the best they can do, since the git push protocol does not specify what the HEAD is, and they don't want to default to a name like "master".
If git-annex sync pushed master before git-annex and synced/master, it would avoid this problem. But pushing master to a non-bare remote often fails due to non-fast-forward, and so the stderr of the master push is discarded to avoid displaying an error message. Which also prevents seeing the progress display for that push. So, it pushes synced/master before master in order for the data transfer and progress display to be done there. It is possible to at least push git-annex after synced/master, but that will leave github defaulting to synced/master in this case, which remains weird behavior. Oh well, it's a behavior apparently specific to github, and I can't see a good way for git-annex to avoid it given its other constraints.