git-annex/doc/git-annex-reinit.mdwn

# NAME

git-annex reinit - initialize repository, reusing old UUID

# SYNOPSIS

git annex reinit `uuid|description`

# DESCRIPTION

Normally, initializing a repository generates a new, unique identifier
(UUID) for that repository. Occasionally it may be useful to reuse a
UUID -- for example, if a repository got deleted, and you're
setting it back up.

Use this with caution; it can be confusing to have two existing
repositories with the same UUID. 

Make sure you run `git annex fsck` after changing the UUID of a
repository to make sure location tracking information is recorded
correctly.

Like `git annex init`, this attempts to enable any special remotes
that are configured with autoenable=true.

# OPTIONS

* `--json`

  Enable JSON output. This is intended to be parsed by programs that use
  git-annex.

* `--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-init]](1)

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

# AUTHOR

Joey Hess <id@joeyh.name>

Warning: Automatically converted into a man page by mdwn2man. Edit with care.
finished splitting out man pages for all commands 2015-03-25 16:09:49 +00:00			`# NAME`

			`git-annex reinit - initialize repository, reusing old UUID`

			`# SYNOPSIS`

			git annex reinit `uuid\|description`

			`# DESCRIPTION`

			`Normally, initializing a repository generates a new, unique identifier`
			`(UUID) for that repository. Occasionally it may be useful to reuse a`
			`UUID -- for example, if a repository got deleted, and you're`
			`setting it back up.`

			`Use this with caution; it can be confusing to have two existing`
reusing repository uuid cannot result in data loss AFAIK Avoiding such problems is one reason why git-annex does active verification of other copies of a file when dropping. You could argue that reusing the uuid of a trusted repository leads to data loss, but that data loss doesn't really involve reusing the uuid, but instead is caused by deleting a trusted repository. Using trusted repositories without a great deal of care is a good way to blow off your foot, of which deleting them is only the most obvious; added some sections about that. If reusing a repository uuid could result in data loss then I'd be on board with making reinit run a fast fsck to update the location log, but since it can't, I feel that is not worth forcing. Not a bad idea to run fsck afterwards. Updated language about that. This commit was sponsored by Jake Vosloo on Patreon. 2017-01-30 16:54:32 +00:00			`repositories with the same UUID.`

			Make sure you run `git annex fsck` after changing the UUID of a
			`repository to make sure location tracking information is recorded`
			`correctly.`
finished splitting out man pages for all commands 2015-03-25 16:09:49 +00:00
Special remotes configured with autoenable=true will be automatically enabled when git-annex init is run. 2015-09-14 18:49:48 +00:00			Like `git annex init`, this attempts to enable any special remotes
			`that are configured with autoenable=true.`

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`

reinit: Support --json and --json-error-messages Basically same concerns as init.. Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project 2023-05-08 19:06:19 +00:00			* `--json`

			`Enable JSON output. This is intended to be parsed by programs that use`
			`git-annex.`

			* `--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
finished splitting out man pages for all commands 2015-03-25 16:09:49 +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-init]](1)`

use stronger wording in reinit regarding fsck 2017-01-17 19:33:36 +00:00			`[[git-annex-fsck]](1)`

finished splitting out man pages for all commands 2015-03-25 16:09:49 +00:00			`# AUTHOR`

			`Joey Hess <id@joeyh.name>`

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