git-annex/doc/git-annex-trust.mdwn

# NAME

git-annex trust - trust a repository

# SYNOPSIS

git annex trust `[repository ...]`

# DESCRIPTION

Records that a repository is trusted to not unexpectedly lose
content. Use with care.

Repositories can be specified using their remote name, their
description, or their UUID. To trust the current repository, use "here".

Before trusting a repository, consider this scenario. Repository A
is trusted and B is not; both contain the same content. `git-annex drop`
is run on repository A, which checks that B still contains the content,
and so the drop proceeds. Then `git-annex drop` is run on repository B,
which trusts A to still contain the content, so the drop succeeds. Now
the content has been lost.

# OPTIONS

* `--json`

  Enable JSON output. This is intended to be parsed by programs that use
  git-annex. Each line of output is a JSON object.

* `--json-error-messages`

  Messages that would normally be output to standard error are included in
  the JSON instead.

* Also the [[git-annex-common-options]](1) can be used.

# SEE ALSO

[[git-annex]](1)

[[git-annex-semitrust]](1)

[[git-annex-untrust]](1)

[[git-annex-dead]](1)

# AUTHOR

Joey Hess <id@joeyh.name>

Warning: Automatically converted into a man page by mdwn2man. Edit with care.
separated man pages for all the setup commands while at the gate in ATL 2015-03-23 22:20:42 +00:00			`# NAME`

			`git-annex trust - trust a repository`

			`# SYNOPSIS`

			git annex trust `[repository ...]`

			`# DESCRIPTION`

			`Records that a repository is trusted to not unexpectedly lose`
			`content. Use with care.`

			`Repositories can be specified using their remote name, their`
			`description, or their UUID. To trust the current repository, use "here".`

Behavior change: git-annex trust now needs --force Since unconsidered use of trusted repositories can lead to data loss. Trusted has always been this way, but it used to be acceptable for git-annex to be set up so that data could be lost without using --force, and most or all other ways that can happen have already been eliminated. This commit was sponsored by Mark Reidenbach on Patreon. 2021-01-07 13:59:52 +00:00			`Before trusting a repository, consider this scenario. Repository A`
			is trusted and B is not; both contain the same content. `git-annex drop`
			`is run on repository A, which checks that B still contains the content,`
			and so the drop proceeds. Then `git-annex drop` is run on repository B,
			`which trusts A to still contain the content, so the drop succeeds. Now`
			`the content has been lost.`

split out common options to its own page and mention it on each subcommand page Sometimes users would get confused because an option they were looking for was not mentioned on a subcommand's man page, and they had not noticed that the main git-annex man page had a list of common options. This change lets each subcommand mention the common options, similarly to how the matching options are handled. This commit was sponsored by Svenne Krap on Patreon. 2021-05-10 19:00:13 +00:00			`# OPTIONS`

expire, trust et al, dead, describe: Support --json and --json-error-messages For expire, the normal output is unchanged, but the --json output includes the uuid in machine parseable form. Which could be very useful for this somewhat obscure command. That needed ActionItemUUID to be implemented, which seemed like a lot of work, but then --- I had been going to skip implementing them for trust, untrust, dead, semitrust, and describe, but putting the uuid in the json is useful information, it tells what uuid git-annex picked given the input. It was not hard to support these once ActionItemUUID was implemented. Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project 2023-05-05 19:29:49 +00:00			* `--json`

			`Enable JSON output. This is intended to be parsed by programs that use`
			`git-annex. Each line of output is a JSON object.`

			* `--json-error-messages`

			`Messages that would normally be output to standard error are included in`
			`the JSON instead.`

			`* Also the [[git-annex-common-options]](1) can be used.`
split out common options to its own page and mention it on each subcommand page Sometimes users would get confused because an option they were looking for was not mentioned on a subcommand's man page, and they had not noticed that the main git-annex man page had a list of common options. This change lets each subcommand mention the common options, similarly to how the matching options are handled. This commit was sponsored by Svenne Krap on Patreon. 2021-05-10 19:00:13 +00:00
separated man pages for all the setup commands while at the gate in ATL 2015-03-23 22:20:42 +00:00			`# SEE ALSO`

			`[[git-annex]](1)`

expand manpages cross-references significantly 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. 2015-05-29 16:12:55 +00:00			`[[git-annex-semitrust]](1)`

			`[[git-annex-untrust]](1)`

			`[[git-annex-dead]](1)`

separated man pages for all the setup commands while at the gate in ATL 2015-03-23 22:20:42 +00:00			`# AUTHOR`

			`Joey Hess <id@joeyh.name>`

			`Warning: Automatically converted into a man page by mdwn2man. Edit with care.`