7189dfd77d
* webapp: Detect when upgrades are available, and upgrade if the user
desires.
(Only when git-annex is installed using the prebuilt binaries
from git-annex upstream, not from eg Debian.)
* assistant: Detect when the git-annex binary is modified or replaced,
and either prompt the user to restart the program, or automatically
restart it.
* annex.autoupgrade configures both the above upgrade behaviors.
* Added support for quvi 0.9. Slightly suboptimal due to limitations in its
interface compared with the old version.
* Bug fix: annex.version did not get set on automatic upgrade to v5 direct
mode repo, so the upgrade was performed repeatedly, slowing commands down.
* webapp: Fix bug that broke switching between local repositories
that use the new guarded direct mode.
* Android: Fix stripping of the git-annex binary.
* Android: Make terminal app show git-annex version number.
* Android: Re-enable XMPP support.
* reinject: Allow to be used in direct mode.
* Futher improvements to git repo repair. Has now been tested in tens
of thousands of intentionally damaged repos, and successfully
repaired them all.
* Allow use of --unused in bare repository.
# imported from the archive
59 lines
2.1 KiB
Markdown
59 lines
2.1 KiB
Markdown
Git-annex supports several levels of trust of a repository:
|
|
|
|
* semitrusted (default)
|
|
* untrusted
|
|
* trusted
|
|
* dead
|
|
|
|
## semitrusted
|
|
|
|
Normally, git-annex does not fully trust its stored [[location_tracking]]
|
|
information. When removing content, it will directly check
|
|
that other repositories have enough [[copies]].
|
|
|
|
Generally that explicit checking is a good idea. Consider that the current
|
|
[[location_tracking]] information for a remote may not yet have propagated
|
|
out. Or, a remote may have suffered a catastrophic loss of data, or itself
|
|
been lost.
|
|
|
|
There is still some trust involved here. A semitrusted repository is
|
|
depended on to retain a copy of the file content; possibly the only
|
|
[[copy|copies]].
|
|
|
|
(Being semitrusted is the default. The `git annex semitrust` command
|
|
restores a repository to this default, when it has been overridden.
|
|
The `--semitrust` option can temporarily restore a repository to this
|
|
default.)
|
|
|
|
## untrusted
|
|
|
|
An untrusted repository is not trusted to retain data at all. Git-annex
|
|
will retain sufficient [[copies]] of data elsewhere.
|
|
|
|
This is a good choice for eg, portable drives that could get lost. Or,
|
|
if a disk is known to be dying, you can set it to untrusted and let
|
|
`git annex fsck` warn about data that needs to be copied off it.
|
|
|
|
To configure a repository as untrusted, use the `git annex untrust`
|
|
command.
|
|
|
|
## trusted
|
|
|
|
Sometimes, you may have reasons to fully trust the location tracking
|
|
information for a repository. For example, it may be an offline
|
|
archival drive, from which you rarely or never remove content. Deciding
|
|
when it makes sense to trust the tracking info is up to you.
|
|
|
|
One way to handle this is just to use `--force` when a command cannot
|
|
access a remote you trust. Or to use `--trust` to specify a repisitory to
|
|
trust temporarily.
|
|
|
|
To configure a repository as fully and permanently trusted,
|
|
use the `git annex trust` command.
|
|
|
|
## dead
|
|
|
|
This is used to indicate that you have no trust that the repository
|
|
exists at all. It's appropriate to use when a drive has been lost,
|
|
or a directory irretrevably deleted. It will make git-annex avoid
|
|
even showing the repository as a place where data might still reside.
|