aboutsummaryrefslogtreecommitdiff
path: root/doc/git-annex-unlock.mdwn
Commit message (Collapse)AuthorAge
* better doc for --json-error-messagesGravatar Joey Hess2018-02-19
| | | | Word so warnings can be included, not only errors.
* add --json-error-messages (not yet implemented)Gravatar Joey Hess2018-02-19
| | | | | | | | | | Added --json-error-messages option, which includes error messages in the json output, rather than outputting them to stderr. The actual rediretion of errors is not implemented yet, this is only the docs and option plumbing. This commit was supported by the NSF-funded DataLad project.
* unlock, lock: Support --json.Gravatar Joey Hess2017-10-30
|
* TypoGravatar tim@5431dd39464df207b7d46d3cf1bc74c82123ac682016-04-01
|
* annex.thinGravatar Joey Hess2015-12-27
| | | | | | | | | | | | | | Decided it's too scary to make v6 unlocked files have 1 copy by default, but that should be available to those who need it. This is consistent with git-annex not dropping unused content without --force, etc. * Added annex.thin setting, which makes unlocked files in v6 repositories be hard linked to their content, instead of a copy. This saves disk space but means any modification of an unlocked file will lose the local (and possibly only) copy of the old version. * Enable annex.thin by default on upgrade from direct mode to v6, since direct mode made the same tradeoff. * fix: Adjusts unlocked files as configured by annex.thin.
* v6 git-annex unlockGravatar Joey Hess2015-12-10
| | | | | | | | | | | Note that the implementation uses replaceFile, so that the actual replacement of the work tree file is atomic. This seems a good property to have! It would be possible for unlock in v6 mode to be run on files that do not have their content present. However, that would be a behavior change from before, and I don't see any immediate need to support it, so I didn't implement it.
* expand manpages cross-references significantlyGravatar Antoine Beaupré2015-05-29
| | | | | | | | | | | | | | | | | | i found that most man pages only had references to the main git-annex manpage, which i stillfind pretty huge and hard to navigate through. i tried to sift through all the man pages and add cross-references between relevant pages. my general rule of thumb is that links should be both ways unless one of the pages is a more general page that would become ridiculously huge if all backlinks would be added (git-annex-preferred-content comes to mind). i have also make the links one per line as this is how it was done in the metadata pages so far. i did everything but the plumbing, utility and test commands, although some of those are linked from the other commands so cross-links were added there as well.
* splitting up the man pageGravatar Joey Hess2015-03-23
Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..