[[!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 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 that's not accessible and `git-annex init` will
warn about such a remote.
"""]]
