summaryrefslogtreecommitdiff
path: root/doc/walkthrough/unused_data.mdwn
Commit message (Collapse)AuthorAge
* dropunused behavior change: Now refuses to drop the last copy of a file, ↵Gravatar Joey Hess2013-07-25
| | | | | | | | | | unless you use the --force. This was the last place in git-annex that could remove data referred to by the git history, without being forced. Like drop, dropunused checks remotes, and honors the global annex.numcopies setting. (However, .gitattributes settings cannot apply to unused files.)
* --unused: New switch that makes git-annex operate on all data found by the ↵Gravatar Joey Hess2013-07-03
| | | | last run of git annex unused. Supported by fsck, get, move, copy.
* deseqGravatar Joey Hess2012-05-02
|
* fix broken linksGravatar Joey Hess2011-11-08
|
* use SHA256 by defaultGravatar Joey Hess2011-11-04
| | | | | | | | | | | | | | | | | | | | | | | | To get old behavior, add a .gitattributes containing: * annex.backend=WORM I feel that SHA256 is a better default for most people, as long as their systems are fast enough that checksumming their files isn't a problem. git-annex should default to preserving the integrity of data as well as git does. Checksum backends also work better with editing files via unlock/lock. I considered just using SHA1, but since that hash is believed to be somewhat near to being broken, and git-annex deals with large files which would be a perfect exploit medium, I decided to go to a SHA-2 hash. SHA512 is annoyingly long when displayed, and git-annex displays it in a few places (and notably it is shown in ls -l), so I picked the shorter hash. Considered SHA224 as it's even shorter, but feel it's a bit weird. I expect git-annex will use SHA-3 at some point in the future, but probably not soon! Note that systems without a sha256sum (or sha256) program will fall back to defaulting to SHA1.
* update documentation for new, neutered key-value backendsGravatar Joey Hess2011-08-28
| | | | | | | | | | | Backends are now only used to generate keys (and check them); they are not arbitrary key-value stores for data, because it turned out such a store is better modeled as a special remote. Updated docs to not imply backends do more than they do now. Sometimes I'm tempted to rename "backend" to "keytype" or something, which would really be more clear. But it would be an annoying transition for users, with annex.backends etc.
* improve unused command's outputGravatar Joey Hess2011-05-28
| | | | | Display the name of the remote being checked, with "." for the current remote, echoing the way describe takes that to change its description.
* unused/dropunused: support --fromGravatar Joey Hess2011-04-02
|
* initial pass at doc updateGravatar Joey Hess2011-03-15
|
* split the walkthrough and inline back togetherGravatar Joey Hess2011-02-27