Comments in the moderation queue:
Recent comments posted to this site:
It's fine to annex the big files and store the small files in git in
the usual way.
The find | xargs approach should work.
find | xargs
You can also use the git-annex-matching-options, eg:
git annex add --include='*.adi'
git annex add --largerthan=1mb
You can also configure git-annex to know which files you consider
large, so that git annex add will annex the large ones and add
the rest to git not the annex. See largefiles
git annex add
If you're finding vicfg confusing, you don't have to use it; the same
configuration can be done at the command line using git annex wanted.
See preferred content for documentation.
git annex wanted
If you just want to have full control over what files are stored in the
local repository, the easiest way to do that is to run git annex get and
git annex drop manually when you want or don't want a file's content,
and don't pass --content to git annex sync.
git annex get
git annex drop
git annex sync
The disk-free-space and mountpoints dependencies will need to be backported
to Debian jessie before git-annex's backport can be updated. Both packages
are available in testing, so should be fairly easy to backport.
I'm not sure about creating a branch, but I use https://git-annex.branchable.com/git-annex-find/ to list locally available files.
Have a look at https://git-annex.branchable.com/git-annex-reinject/
--batch mode should be usable to get current metadata, set new
metadata, and remove existing metadata. The non-batch metadata command has
different syntaxes for all of these, but it would be good to have a single
interface that handles all three in batch mode.
It could read a line containing the file or key, with any metadata
fields that should be changed:
And reply with all the metadata, in nearly the same format:
And that reply could in turn be edited and fed back in to change the
There's a DRY problem here because there's the current JSON generator code,
and I'd have to add an Aeson parser to parse the JSON input. But, Aeson
parsers also automatically have a matching generator, which is guaranteed
to generate code that the parser can parse.
So, it would be nice to use the Aeson JSON generator, instead of the
current one, but that can only be done if the JSON is formatted the same,
or close enough that nothing currently consuming metadata --json will