Recent comments posted to this site:
In TRANSFEREXPORT STORE|RETRIEVE Key File Name
, it should always
be possible for the File to not contain spaces in its name. But it could be
rather painful for git-annex to avoid spaces in some cases (would need to
link or copy the annexed file content). So well spotted.
Hmm, it's actually possible for a Key to contain spaces as well, at least with the WORM backend. external special remote protocol broken by key with spaces
The protocol VERSION
is picked by the special remote, it's not
negotiated.
That is entirely out of scope. You're looking for a way to store a git repository someplace like S3. Such things exist already, and are not git-annex and I'm not going to replicate them as part of this feature.
That sounds much more like a regular remote with git annex copy --all
.
This entire design is preducated on exporting a single treeish. If you want to make a single treeish containing all versions of every file ...
It would be awesome to be able to move (or copy) between remotes,
eg. git annex copy --from=remote-a --to=remote-b
Use case: I have a repo of ~1TB, but only ~30GB free disk space on my laptop. Currently I have to manually get
and move
the files almost one by one to get them from one remote to the other.
I couldn't get this to run and had a lot of performance issues with rclone on Google Drive, so I adapted the rclone wrapper to gdrive. It's running fine so far, so I thought I share it:
Also, it's not safe to merge two separate git repositories that have been tuned differently (or one tuned and the other one not). git-annex will prevent merging their git-annex branches together, but it cannot prevent git merge remote/master merging two branches, and the result will be ugly at best (git annex fix can fix up the mess somewhat).
My main use repo is 1.7TB large and holds 172.000+ annexed files. Variations in filename case has lead to a number of file duplications that are still not solved (I have base scripts that can be used to flatten filename case and fix references in other files, but it will probably mean handling some corner cases and there are more urgent matters for now).
For these reasons I'm highly interested in the lowercase option and I'm probably not the only one in a similar case.
Does migrating to a tuned repository mean unannexing everything and reimporting into a newly created annex, replica by replica then sync again? That's a high price in some setup. Or is there a way to somehow git annex sync
between a newly created repo and an old, untuned one?
In some cases, if remote supports versioning, might be cool to be able to export all versions (from previously exported point, assuming linear progression). Having a chat with https://quiltdata.com/ folks, project which I just got to know about. 1. They claim/hope to provide infinite storage for public datasets 2. They do support "File" model, so dataset could simply contain files. If we could (ab)use that -- sounds like a lovely free ride 3. They do support versioning. If we could export all the versions -- super lovely.
Might also help to establish interoperability between the tools