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.) |
||
|---|---|---|
| .. | ||
| AWS.hs | ||
| Delete.hs | ||
| Edit.hs | ||
| Fsck.hs | ||
| IA.hs | ||
| Local.hs | ||
| Pairing.hs | ||
| Preferences.hs | ||
| Ssh.hs | ||
| Unused.hs | ||
| Upgrade.hs | ||
| WebDAV.hs | ||