809ddd9df8
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.
38 lines
896 B
Markdown
38 lines
896 B
Markdown
# 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.
|