Recent comments posted to this site:

comment 23 70dcb7e7ffdd14351adaf4c40ee7fdd0
[[!comment Error: unsupported page format hs]]
Sun Aug 20 10:26:41 2017
comment 3 e6ce9bb92c973350852c9498b7ffb50f
[[!comment Error: unsupported page format sh]]
Sun Aug 20 10:26:41 2017

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.

Comment by joey Tue Aug 15 18:18:14 2017

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.

Comment by joey Tue Aug 15 18:16:31 2017

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 ...

Comment by joey Tue Aug 15 18:13:38 2017
It would be great to have an option to include git history in the export, such that a special remote could be used both to rebuild a repository and to view the contents.
Comment by xloem Thu Aug 10 00:25:27 2017

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.

Comment by lykos Wed Jul 26 19:08:07 2017

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:

https://github.com/Lykos153/git-annex-remote-gdrive

Comment by lykos Fri Jul 21 23:56:12 2017

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?

Comment by https://launchpad.net/~stephane-gourichon-lpad Tue Jul 18 11:49:10 2017

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

Comment by yarikoptic Fri Jul 14 20:10:42 2017