mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Special remotes configured with autoenable=true will be automatically enabled when git-annex init is run.

Browse source
This commit is contained in:
Joey Hess 2015-09-14 14:49:48 -04:00
parent 3f47d1b351
commit 9cfb96c53d
12 changed files with 148 additions and 64 deletions
Download patch file Download diff file Expand all files Collapse all files

16
doc/git-annex-enableremote.mdwn
View file

@ -19,14 +19,14 @@ special remote names.
Some special remotes may need parameters to be specified every time they are
enabled. For example, the directory special remote requires a directory=
parameter.
parameter every time.
This command can also be used to modify the configuration of an existing
special remote, by specifying new values for parameters that were
originally set when using initremote. (However, some settings such as
special remote, by specifying new values for parameters that are
usually set when using initremote. (However, some settings such as
the as the encryption scheme cannot be changed once a special remote
has been created.)
The GPG keys that an encrypted special remote is encrypted with can be
changed using the keyid+= and keyid-= parameters. These respectively
add and remove keys from the list. However, note that removing a key
@ -45,6 +45,12 @@ on files that have already been copied to the remote. Hence using
keyid+= and keyid-= with such remotes should be used with care, and
make little sense except in cases like the revoked key example above.
If you get tired of manually enabling a special remote in each new clone,
you can pass "autoenable=true". Then when [[git-annex-init]](1) is run in
a new clone, it will will attempt to enable the special remote. Of course,
this works best when the special remote does not need anything special
to be done to get it enabled.
# SEE ALSO
[[git-annex]](1)

8
doc/git-annex-init.mdwn
View file

@ -16,6 +16,14 @@ 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 disable this, 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.
# SEE ALSO
[[git-annex]](1)

6
doc/git-annex-initremote.mdwn
View file

@ -36,6 +36,12 @@ encryption=pubkey, content in the special remote is directly encrypted
to the specified GPG keys, and additional ones cannot easily be given
access.
If you anticipate using the new special remote in other clones of the
repository, you can pass "autoenable=true". Then when [[git-annex-init]](1)
is run in a new clone, it will attempt to enable the special remote. Of
course, this works best when the special remote does not need anything
special to be done to get it enabled.
# OPTIONS
* `--fast`

3
doc/git-annex-reinit.mdwn
View file

@ -17,6 +17,9 @@ Use this with caution; it can be confusing to have two existing
repositories with the same UUID. Also, you will probably want to run
a fsck.
Like `git annex init`, this attempts to enable any special remotes
that are configured with autoenable=true.
# SEE ALSO
[[git-annex]](1)

17
doc/todo/autoenable__61__true_for_special_remotes.mdwn
View file

@ -1,3 +1,20 @@
Just passing along from https://github.com/datalad/datalad/issues/77#issuecomment-134688459
joey: I do think there could be a use case for configuring a special remote with autoenable=true and have git-annex init try to enable all such remotes.
> [[done]], I made both `git init` and `git annex reinit` auto-enable
> such special remotes. For now, the assistant does not (could change).
>
> There was also the question of what to do when git-annex auto-inits
> in a clone of a repository. It wouldn't do for a command like
> `git annex find`'s output to include any messages that might be shown while
> auto-enabling special remotes as a result of an auto-init.
> Since I can't guarantee enabling special remotes will be quiet, I've not
> tried to auto-enable special remotes in this case.
>
> I think I'd have to
> exec a git-annex init process with stdout sent to stderr to implement
> this in a safe way, and due to calls to ensureInitialized in Remote.Git,
> which can auto-init a local remote, that gets particularly tricky. Best, I
> feel, to wait and see if anyone needs that.
--[[Joey]]