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.

# 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.`

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.`