new microfeatures

I'm soliciting ideas for new small features that let git-annex do things that currently have to be done manually or whatever.

Here are a few I've been considering:

--numcopies would be a useful command line switch.

Update: Added. Also allows for things like git annex drop --numcopies=2 when in a repo that normally needs 3 copies, if you need to urgently free up space.
A way to make drop and other commands temporarily trust a given remote, or possibly all remotes.

Combined, this would allow git annex drop --numcopies=2 --trust=repoa --trust=repob to remove files that have been replicated out to the other 2 repositories, which could be offline. (Slightly unsafe, but in this case the files are podcasts so not really.)

Update: done --Joey

wishlist: git-annex replicate suggests some way for git-annex to have the smarts to copy content around on its own to ensure numcopies is satisfied. I'd be satisfied with a git annex copy --to foo --if-needed-by-numcopies

Contrary to the "basic" solution, I would love to have a git annex distribute which is smart enough to simply distribute all data according to certain rules. My ideal, personal use case during the next holidays where I will have two external disks, several SD cards with 32 GB each and a local disk with 20 GB (yes....) would be:

cd ~/photos.annex # this repository does not have any objects!
git annex inject --bare /path/to/SD/card  # this adds softlinks, but does **not** add anything to the index. it would calculate checksums (if enabled) and have to add a temporary location list, though
git annex distribute # this checks the config. it would see that my two external disks have a low cost where>

comment 3

Last edited Tue Jul 17 17:54:57 2012

Thanks for creating git-annex.

I am confused about the advantages of the SHA* backends over WORM. The "backends" page in this wiki says that with WORM, files "can be moved around, but should never be added to or changed". But I don't see any difference to SHA* files as long as the premise of WORM that "any file with the same basename, size, and modification time has the same content" is true. Using "git annex unlock", WORM files can be modified in the same way as SHA* files.

If the storage I use is dependable (i.e. I don't need SHA checksums for detection of corruption), and I don't need to optimize for the case that the modification date of a file is changed but the contents stay the same, and if it is unlikely that several files will be identical, is there actually any advantage in using SHA*?

comment 1

You're right -- as long as nothing changes a file without letting the modification time update, editing WORM files is safe.

Comment by http://joey.kitenet.net/ — Mon Aug 29 16:10:38 2011

Comments on this page are closed.

Last edited Tue Jul 17 17:54:57 2012

I'm soliciting ideas for new small features that let git-annex do things that currently have to be done manually or whatever.

Here are a few I've been considering:

--numcopies would be a useful command line switch.

Update: Added. Also allows for things like git annex drop --numcopies=2 when in a repo that normally needs 3 copies, if you need to urgently free up space.
A way to make drop and other commands temporarily trust a given remote, or possibly all remotes.

Update: done --Joey

Contrary to the "basic" solution, I would love to have a git annex distribute which is smart enough to simply distribute all data according to certain rules. My ideal, personal use case during the next holidays where I will have two external disks, several SD cards with 32 GB each and a local disk with 20 GB (yes....) would be:

cd ~/photos.annex # this repository does not have any objects!
git annex inject --bare /path/to/SD/card  # this adds softlinks, but does **not** add anything to the index. it would calculate checksums (if enabled) and have to add a temporary location list, though
git annex distribute # this checks the config. it would see that my two external disks have a low cost where>

comment 3




Good point. scp fixes this by using a colon, but as colons aren't needed in git-annex remotes' names... -- RichiH





Comment by



https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U




— Wed Apr 20 21:28:06 2011

Last edited Tue Jul 17 17:54:57 2012