NAME
git-annex reregisterurl - updates url registration information
SYNOPSIS
git annex reregisterurl [key]
DESCRIPTION
This plumbing-level command updates information about the urls that are registered for a key.
OPTIONS
--move-from=name|uuidFor each key, update any urls that are currently claimed by the specified remote to be instead used by the web special remote.
This could be used eg, when a special remote was needed to provide authorization to get an url, but the url has now become publically available and so the web special remote can be used.
Note that, like
git-annex unregisterurl, using this option unregisters an url from a special remote, but it does not mark the content as not present in that special remote. However, likegit-annex registerurl, this option does mark content as being present in the web special remote.--batchIn batch input mode, lines are read from stdin, and each line should contain a key.
-zWhen in batch mode, the input is delimited by nulls instead of the usual newlines.
--jsonEnable JSON output. This is intended to be parsed by programs that use git-annex. Each line of output is a JSON object.
--json-error-messagesMessages that would normally be output to standard error are included in the JSON instead.
Also the git-annex-common-options(1) can be used.
SEE ALSO
git-annex(1)
AUTHOR
Joey Hess id@joeyh.name
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
But then how to mark "not present" in that remote? After
git-annex-reregisterurlI still have[datalad]remote listed although url now, correctly, associated withweb. I have trieddropbut that didn't workCould there may be option
--fullyor--mark-not-presentoption to make it 1 invocation operation?You can use
git-annex setpresentkeyto tell git-annex that content is not present in your special remote.Usually whether or not an url is currently registered with a special remote does not affect whether content is actually stored in it, which is why these are 2 different things. Except for the web special remote, which is a special case. I guess yours special remote also may be a special case, but git-annex doesn't know about it, and so why not use setpresentkey to handle the special case, rather than further complicating reregisterurl with it?
Thank you Joey!
or in the other words, "not that special" after all. I see it just a common enough pattern for use of this new
reregisterurlthat in my case it would be easier to just add an option instead of chaining manuallyreregisterurl, figure out what key one way or another, callsetpresentkeywith0. After all it is for a user to announce one way or another.Anyways, I am ok for now, hopefully would not forget next time I use it to chase with that extra invocation.