Recent comments posted to this site:

addendum: note that filecoin itself is not permanent, the server needs to keep recreating deals for the data. a permanent solution would be something like arweave, a permastorage blockchain with tools, which is one of the solutions i found in the ethereum storage docs.
Comment by xloem Tue Feb 22 20:33:31 2022

ipfs appears to be running some free storage services for large files on ipfs backed by filecoin. https://nft.storage/ and htps://web3.storage/ are both presently ostensibly free and permanent and have cli interfaces to upload to them.

Comment by xloem Tue Feb 22 20:33:31 2022

@xloem I'm not sure how services that have CLI interfaces to upload files to them, and then presumably pin them in IPFS are relevant to this IPFS special remote?

Your history of good comments is keeping me from deleting the above 2 as spam, but...

Comment by joey Tue Feb 22 20:33:31 2022

https://nft.storage/terms/ claims this is limited to NFTs and not other data. (Whatever that means; why can't I mint a NFT for a nice gpg encrypted blob?)

I also doubt it actually will store anything for longer than the current NFT mania; the terms have a loophole that allow them to provide 90 days notice before ending the service.

It does have an API if someone wants to build a special remote and use it for general data storage. But that's out of scope for this IPFS special remote AFAICS.

Comment by joey Tue Feb 22 20:33:31 2022

I agree, submodules are the usual way to nest git repositories, and will more or less just work with git-annex.

I think that the author of this tip is wanting to version control the contents of .git itself. Eg, to version control .git/config and .git/hooks/.

One problem with this approach is that when the outer repository has "dotgit/annex/objects/files added to it, runninggit-annex dropinside the nested git repository will drop the content, but the outer repository will still contain a copy too. You would have to usegit-annex unused` to eventually clean up those copies. And it stores 2 copies of every annexed file to use it this way.

Comment by joey Tue Jan 25 17:12:46 2022

Using nested git repositories is well possible; if they are checked in they are called submodules, otherwise they just sit there unadded.

Apart from some odd quirx you never run into in normal operation, submodules work fine also with git-annex.

Comment by https://christian.amsuess.com/chrysn Wed Jan 19 14:06:40 2022
For systems (such as rsync.net) that allow us to use both rsync and git-annex, which is the better option? I noticed that the default for rsync.net was this type (gcrypt), does it provide additional capabilities or perform slightly better than the rsync version?
Comment by aaron Tue Jan 11 23:47:08 2022

The gcrypt special remote is for use with the git-remote-gcrypt protocol for making encrypted git remotes. The rsync special remote can also encrypt the files it stores, but it's not related to git-remote-gcrypt; it just puts files in a plain directory tree using rsync.

If you want to keep a repository remote (not a special remote) on your rsync.net host, and want it to be encrypted, then you can use git-remote-gcrypt and use this special remote so that the data is all together. If you're not using git-remote-gcrypt, then the rsync special remote is what you want.

Comment by tomdhunt Tue Jan 11 23:47:08 2022

@tomdhunt, Are you saying that the difference is the rsync remote only contains the files and the actual history stuff from git isn't tracked in it while the git-remote-gcrypt one also tracks history because it is a bare git repo?

Additionally, I just started trying out the grcrypt version on rsync.net and it seems to use a slightly different initialization when compared to the others. I've made some progress, but I am still not quite able to make it work, it seems that I'm having issues initializing the bare remote when I do it via the terminal. If I don't try to create a bare and push it the first commit completely fails, I seem to be able to make more progress by creating a bare, pushing it, and then adding it (but it still fails). This is what I have got to so far:

user@localhost:$ sudo chown <rsync.net user>:<rsync.net user> -R
user@localhost:$ git init --bare shared=group test_repo.git
user@localhost:$ sudo rsync -vrSP test_repo.git <rsync.net user>@<server>:annex
user@localhost:$ git annex initremote "<some_userful_name>" type=gcrypt gitrepo=<rsync.net user>@<server>:annex chunk=1MiB keyid=<key_id> encryption=shared mac=HMACSHA512 autoenable=true

The error message that I get:

user@localhost:$ git annex sync
commit 
On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)
ok
pull <rsync.net server> 
gcrypt: Decrypting manifest
gpg: selecting card failed: No such device
gpg: Signature made Sun 09 Jan 2022 08:26:18 AM GMT
gpg:                using EDDSA key <key>
gpg: Good signature from "<key comment>" [ultimate]

merge: refs/remotes/<remote name>/master - not something we can merge

merge: refs/remotes/<remote name>/synced/master - not something we can merge
failed
sync: 1 failed

It also looks like this method fails to add gcrypt-participants = <key> and gcrypt-signingkey = <key> to the .git/config file like webapp does.

Furthermore, when I use the git annex webapp to generate the repo, it does something that seems to be even more different (and successfully creates the bare repo by itself), specifically the URL looks something like this:

url = gcrypt::<rsync.net user>@git-annex-.<country>.2D<server_subname?>.2E<server_name>.2E<server_domain>-<rsync.net user>_22_annex:annex/

It seems to be encoding some of the characters to make a URL? Is there another web API that we can interact with?

Comment by aaron Tue Jan 11 23:47:08 2022
Are we still concerned about this (and does this still apply if we are using encrypted remotes?)? I do have my normal git stuff configured to use GPG signing because I like the concept, but noticed that when running git annex webapp the automated commits seemed to bypass my normal global git config and not add a signature.
Comment by aaron Tue Jan 11 23:47:08 2022