auto-init autoenable=yes

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.)
This commit is contained in:
Joey Hess 2020-05-27 11:54:39 -04:00
parent 731815891d
commit 484a74f073
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
16 changed files with 105 additions and 37 deletions

View file

@ -74,6 +74,7 @@ import Logs.Trust
import Logs.Location hiding (logStatus)
import Logs.Web
import Remote.List
import Remote.List.Util
import Config
import Config.DynamicConfig
import Git.Types (RemoteName, ConfigKey(..), fromConfigValue)
@ -286,7 +287,7 @@ remoteFromUUID u = ifM ((==) u <$> getUUID)
findinmap = M.lookup u <$> remoteMap id
{- Re-read remote list in case a new remote has popped up. -}
tryharder = do
void remoteListRefresh
remotesChanged
findinmap
{- Filters a list of remotes to ones that have the listed uuids. -}