Recent comments posted to this site:
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.
@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...
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.
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, running
git-annex dropinside
the nested git repository will drop the content, but the outer repository
will still contain a copy too. You would have to use
git-annex unused`
to eventually clean up those copies. And it stores 2 copies of every
annexed file to use it this way.
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.
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.
@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?
git annex webapp
the automated commits seemed to bypass my normal global git config and not add a signature.