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

comment

Browse source
This commit is contained in:
Joey Hess 2023-04-18 13:09:24 -04:00
parent b32ca4180d
commit 3a402a907f
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 56 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_3_c2c7144fa74bdc455e1bd36b594902c1._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2023-04-18T16:28:40Z"
content="""
Hmm, you could dead it in your fork. The issue would be, if they ever merge
from it, their working repo will get marked as dead.
A `git-annex configremote` would likewise cause them problems if they
merged from your fork, if they rely on autoenabling being enabled. That's
less likely to be a problem to them I suppose.
"""]]

12
doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_4_4f3e9f15fcc96cd98c6915ec68cc471f._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2023-04-18T16:40:57Z"
content="""
A sub-bug here is that enableremote of a normal git remote adding autoenable=false
always fails with
"That is a normal git remote; passing these parameters does not make sense: autoenable=false".
That happens even when the repo is accessible. So there is no way to disable
a normal git remote that has been initremoted with autoenable=true.
"""]]

32
doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_5_ccb5b6960da43a93ff0b7404190c51de._comment Normal file
View file

@ -0,0 +1,32 @@
[[!comment format=mdwn
username="joey"
subject="""comment 5"""
date="2023-04-18T16:49:45Z"
content="""
I retried your example not using a regular git remote, but a special
remote. When the special remote is made inaccessible, it does not fail in
the same way. Actually, the clone doesn't fail at all:
joey@darkstar:~/tmp/dl>datalad clone dsclone autoclone5
[INFO ] special remote made inacessible for testing
[INFO ] Fetching updates for Dataset(/home/joey/tmp/dl/autoclone5)
update(ok): . (dataset)
update(ok): . (dataset)
configure-sibling(ok): . (sibling)
install(ok): /home/joey/tmp/dl/autoclone5 (dataset)
action summary:
configure-sibling (ok: 1)
install (ok: 1)
update (ok: 1)
Likewise `git-annex init` displays the message from the special remote as a warning
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.
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.
"""]]