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

configremote

Browse source 
New command, currently limited to changing autoenable= setting of a special remote.

It will probably never be used for more than that given the limitations on
it.

Sponsored-by: Brock Spratlen on Patreon
This commit is contained in:
Joey Hess 2023-04-18 15:30:49 -04:00
parent 8728695b9c
commit 9155ed1072
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
15 changed files with 184 additions and 21 deletions
Download patch file Download diff file Expand all files Collapse all files

7
doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_5_ccb5b6960da43a93ff0b7404190c51de._comment
View file

@ -23,10 +23,11 @@ Likewise `git-annex init` displays the message from the special remote as a warn
but exits successfully and without autoenabling it.
Compare with datalad's behavior when it is a regular git remote. The failure there
happens because git-annex auto-enables the remote, and the datalad tries to
fetch from it, but the repo is not available.
happens because git-annex auto-enables the remote successfully, and then
datalad tries to fetch from it, but the repo is not available.
So other than the special case of a git remote stored by initremote, this bug's
real impact seems to only be that enableremote can't be used to change the
configuration of a remote in this state.
configuration of a remote that's not accessible and `git-annex init` will
warn about such a remote.
"""]]

18
doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_6_5b6359663efb608b9a78ab17c02be9ee._comment Normal file
View file

@ -0,0 +1,18 @@
[[!comment format=mdwn
username="joey"
subject="""comment 6"""
date="2023-04-18T18:11:18Z"
content="""
Seems that `git-annex configremote` would be very limited in what
configuration it can change. Changing configuration with enableremote
re-runs the `setup` method, which is passed a RemoteConfig with the user's
proposed changes and can either fail if the config is not valid, or return
a RemoteConfig that might not be the same as the input one. Since `setup` also
prepares to use the remote, which is what's failing when the remote is not
accessible, it could not be used by `configremote`.
So, I think autoenable is about the only config setting that it would make
sense for configremote to be able to change. Changing anything else would
risk storing a configuration that `setup` would not allow. Which could
break the remote in arbitrary ways.
"""]]

7
doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_7_995b88efc83f76f14ccb22bc2a6ef4bd._comment Normal file
View file

@ -0,0 +1,7 @@
[[!comment format=mdwn
username="joey"
subject="""comment 7"""
date="2023-04-18T19:29:28Z"
content="""
Implemented `git-annex configremote`
"""]]