Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
commit
40daf7f1dc
5 changed files with 38 additions and 0 deletions
8
doc/forum/Workarounds_for_git-annex.mdwn
Normal file
8
doc/forum/Workarounds_for_git-annex.mdwn
Normal file
|
@ -0,0 +1,8 @@
|
|||
Hello Everyone,
|
||||
I created a set of scripts to work around some limitations in git-annex (although some of this is out of scope for git-annex ) like managing git repos inside a git-annex repo and (emulating) encryption=shared for gcrypt remotes. This is pretty much tailored to my own use-case, but maybe someone else is interested in this.
|
||||
|
||||
You can find the Workarounds alongside a small Guide here:
|
||||
https://github.com/Lukey3332/git-annex-workarounds
|
||||
|
||||
Regards,
|
||||
Lukey
|
3
doc/todo/publicurl_config_for_all_special_remotes.mdwn
Normal file
3
doc/todo/publicurl_config_for_all_special_remotes.mdwn
Normal file
|
@ -0,0 +1,3 @@
|
|||
`publicurl` configuration option was added to S3 special remote to facilitate public access to the files deposited to S3 via their HTTP "frontend". For many remotes (e.g. `rsync`, `directory`, etc) it might happen that the remote location directory is also served by a regular HTTP server. So it sounds very reasonable to enable regular HTTP(/https) access to those files publicly by providing those special remotes with `publicurl` setting so annex could simply try to access those files via http. In particular relevant for the special remotes with `exporttree=true`.
|
||||
|
||||
[[!meta author=yoh]]
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="comment 1"
|
||||
date="2019-01-25T21:34:15Z"
|
||||
content="""
|
||||
Maybe, it'll suffice to just register the URL with the built-in web remote (via addurl, or registerurl and setpresentkey)?
|
||||
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="yarikoptic"
|
||||
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
|
||||
subject="comment 2"
|
||||
date="2019-01-26T00:46:03Z"
|
||||
content="""
|
||||
Yes, it is possible to register a url per each file as a workaround but it is somewhat unnecessary and inflexible: if top url changes, all urls will need to be adjusted.
|
||||
"""]]
|
|
@ -0,0 +1,10 @@
|
|||
ATM I do not see any obvious way to get a list of options supported by a special remote of a given type.
|
||||
|
||||
manpage says
|
||||
|
||||
The remote's configuration is specified by the parameters passed to this command. Different types of special remotes need different configura‐
|
||||
tion values. The command will prompt for parameters as needed.
|
||||
|
||||
and indeed I get asked for e.g. encryption to be explicitly specified (why not to default to none). But it would not even complain if I specify some bogus (mistyped etc) option. I do not see any way (tried different --help's etc) to figure out what options any given special remote actually supports without going online to e.g. https://git-annex.branchable.com/special_remotes/rsync/ for `rsync` special remote. It makes configuration of special remotes not a trivial matter for new users. IMHO there should be some way (mentioned in man of initremote and enableremote) to get information about supported by the remote options, e.g. `git annex getremoteopts TYPE` or alike. I am not sure how it should/would work for custom special remotes since I think protocol ATM doesn't support querying for a list of configuration options. May be `GETCONFIG` interface command could be extended to return a list with of options with description? or some new command be added?
|
||||
|
||||
[[!meta author=yoh]]
|
Loading…
Reference in a new issue