comment
This commit is contained in:
parent
b32ca4180d
commit
3a402a907f
3 changed files with 56 additions and 0 deletions
|
@ -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.
|
||||||
|
"""]]
|
|
@ -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.
|
||||||
|
"""]]
|
|
@ -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.
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue