484a74f073
Try to enable special remotes configured with autoenable=yes when git-annex auto-initialization happens in a new clone of an existing repo. Previously, git-annex init had to be explicitly run to enable them. That was a bit of a wart of a special case for users to need to keep in mind. Special remotes cannot display anything when autoenabled this way, to avoid interfering with the output of git-annex query commands. Any error messages will be hidden, and if it fails, nothing is displayed. The user will realize the remote isn't enable when they try to use it, and can run git-annex init manually then to try the autoenable again and see what failed. That seems like a reasonable approach, and it's less complicated than communicating something across a pipe in order to display it as a side message. Other reason not to do that is that, if the first command the user runs is one like git-annex find that has machine readable output, any message about autoenable failing would need to not be displayed anyway. So better to not display a failure message ever, for consistency. (Had to split out Remote.List.Util to avoid an import cycle.)
70 lines
1.8 KiB
Markdown
70 lines
1.8 KiB
Markdown
# NAME
|
|
|
|
git-annex init - initialize git-annex
|
|
|
|
# SYNOPSIS
|
|
|
|
git annex init `[description]`
|
|
|
|
# DESCRIPTION
|
|
|
|
Until a repository (or one of its remotes) has been initialized,
|
|
git-annex will refuse to operate on it, to avoid accidentally
|
|
using it in a repository that was not intended to have an annex.
|
|
|
|
It's useful, but not mandatory, to initialize each new clone
|
|
of a repository with its own description. If you don't provide one,
|
|
one will be generated using the username, hostname and the path.
|
|
|
|
If any special remotes were configured with autoenable=true,
|
|
this will also attempt to enable them. See [[git-annex-initremote]](1).
|
|
To prevent that, re-enable a remote with "autoenable=false", or
|
|
mark it as dead (see [[git-annex-dead]](1)).
|
|
|
|
This command is entirely safe, although usually pointless, to run inside an
|
|
already initialized git-annex repository.
|
|
|
|
A top-level `.noannex` file will prevent git-annex init from being used
|
|
in a repository. This is useful for repositories that have a policy
|
|
reason not to use git-annex. The content of the file will be displayed
|
|
to the user who tries to run git-annex init.
|
|
|
|
# EXAMPLES
|
|
|
|
# git annex add foo
|
|
git-annex: First run: git-annex init
|
|
# git annex init
|
|
init ok
|
|
# git annex add foo
|
|
add foo ok
|
|
|
|
# OPTIONS
|
|
|
|
* `--version=N`
|
|
|
|
Force the repository to be initialized using a different annex.version
|
|
than the current default.
|
|
|
|
When the version given is one that automatically upgrades to a newer
|
|
version, it will automatically use the newer version instead.
|
|
|
|
* --autoenable
|
|
|
|
Only enable any special remotes that were configured with
|
|
autoenable=true, do not otherwise initialize anything.
|
|
|
|
# SEE ALSO
|
|
|
|
[[git-annex]](1)
|
|
|
|
[[git-annex-describe]](1)
|
|
|
|
[[git-annex-reinit]](1)
|
|
|
|
git-init(1)
|
|
|
|
# AUTHOR
|
|
|
|
Joey Hess <id@joeyh.name>
|
|
|
|
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
|