comment

avoid ugly error message

Http remotes that do expose a git config file, but are not initialized
resulted in an ugly and unncessary error message, now sqelched.

When git-annex-shell configlist is run w/o the autoinit field, it may
not generate a uuid for the repository. So in that case, it's not
unexpected for the config it does list to not include a UUID, and
dumping out the config in a warning message is not needed.

If configlist is asked to autoinit and we don't get back a config with a
UUID in it, that suggests some problem, and what we got back may not be
a config at all but some diagnostic message, so it does make sense to
output it then.

comment

--whatelse is a better name than --describe-other-params

The use case is basically the user having forgotten, so --help would be
best, but it would be quite hard to include this in --help, since it may
even have to spin up an external special remote program.

I also considered --umm but typoed it the first time I tried it as
--uum, and while memorable, it's too cutesy. --whatelse is good because
it explicitly asks, what other params, besides the ones I've given?

Merge branch 'master' of ssh://git-annex.branchable.com

fix --describe-other-params of external when encryption is not specified

Encryption not being specified makes lenientRemoteConfigParser fail
to parse, and so it was not able to start the external up to get
LISTCONFIGS.

include passthrough params in --describe-other-params

initremote --describe-other-params

Does not yet include descriptions from external special remote programs.

Merge branch 'remoteconfig'

add descriptions for all remote config fields

not yet used

gcrypt inherits shellescape setting from rsync, allow it

convert RemoteConfigFieldParser to data type

Merge branch 'master' of ssh://git-annex.branchable.com

speed hack

Avoids the external program being started just to use LISTCONFIGS on an
already accepted config.

So initremote/enableremote will still run the external program an extra
time to use LISTCONFIGS, but everything that uses the special remote after
it's initialized will not any longer.

done

always add the specialRemoteConfigParsers

Was not being added in some places, resulting in error messages about
encryption not being a valid field.

avoid adding parsers for fields that already have a parser

bugfixes

getRemoteConfigPassedThrough was never returning anything, Typeable
prevented the type checker from noticing a dumb mistake.

parseRemoteConfig was not adding Accepted values as PassedThrough

add LISTCONFIGS to external special remote protocol

Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.

The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.

configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.

Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.

Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.

initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.

avoid relying on crazy monoid instance

This code worked as intended, but only by accident, because of this
instance:

instance Monoid b => Monoid (x -> b) where mempty = const (mempty :: b)

Let's be explicit that we throw away the error message.

avoid getting config parser when there is no config to parse

The benefit here is that external special remotes will need a
LISTCONFIGS request and response to generate their config parser,
and this avoids it being done for all the ones that don't have any
configs.

Note that, a config parser could in theory fail to parse if there are no
configs (none currently do), but a parse failure is already thrown away
when generating the remote list because it's too late. Such problems
have to be caught at initremote/enableremote time, not here.

moving under datalad project, since I do not see explicit repronim-specific use case addressed

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

devblog

started on --list-params-for

comment

update

use "param" not "field" to match man pages

fix build of webapp

removed

fix build of assistant

Merge branch 'master' into remoteconfig

remove deleted module

ported Remote.External

Not yet added anything to the protocol to get a list of remote config
fields; any fields will be accepted and are available for the external
remote to use as before.

There is one minor behavior change.. Before, GETCONFIG could be passed a
field such as type, externaltype, encryption, etc, and would get the
value of that. Now, GETCONFIG only works on fields that don't have a
defined meaning to git-annex, so are passed through to the external
remote. This seems unlikely to affect any external special remotes in
practice.

a few more field functions

a few forgotten remote config fields

preferreddir can be used with any special remote, so its parser needs to
be included in the commonFieldParsers.

initremote with uuid= changed to delete that field, so it does not
need to be included in commonFieldParsers. Note that, existing remotes
initialized before this change will have the field in remote.log.
This will not cause problems parsing, because the value will be
Accepted.

Grepping for 'Accepted "' found these, and I'm pretty sure this is all of
them.

use more field functions

Using field functions consistently avoids possibility of typos and also
helps ensure that all fields are added to RemoteConfigParsers (as long
as I have remembered to add them when writing the functions).

include credPairRemoteFields in RemoteConfigParsers

Avoids parse error when the fields are added to RemoteConfig at setup
time and it then gets parsed, also at setup time. After setup time, such
internally added fields are not a problem, because they're Accepted. So
it may not be necessary in all cases to list such internally added
fields, but I think it's a good idea to always do so.

finish porting S3

ported almost all remotes, until my brain melted

external is not started yet, and S3 is part way through and not
compiling yet

convert configParser to Annex action and add passthrough option

Needed so Remote.External can query the external program for its
configs. When the external program does not support the query,
the passthrough option will make all input fields be available.

fix wrong type

Use of Typeable means the type checker can't catch this kind of mistake,
the error is deferred to runtime.

testremote now passes on a directory special remote

removed

removed

removed

separate RemoteConfig parsing basically working

Many special remotes are not updated yet and are commented out.

Added a comment: re: what am I doing wrong?

Added a comment: what am I doing wrong?

Added a comment: preferred way to automate population of the cache upon `get`

Revert spam

This reverts commit c4a33d15b54520ce68b876f0a7dae4497b61a1f2.

Revert spam

This reverts commit a1261c5f364ed50621a519c18b047b2680f5c984.

Revert spam

This reverts commit 1c5edbd823990e547258c964ba6513402a4daae6.

Revert spam

This reverts commit a746c210cc59cecae7e05d92063110055f74ac08.

Revert spam

This reverts commit fa7c78c31de7ef030e823bc525b1b482fae4d06d.

Merge branch 'master' of ssh://git-annex.branchable.com

devblog

wip separate RemoteConfig parsing

Remote now contains a ParsedRemoteConfig. The parsing happens when the
Remote is constructed, rather than when individual configs are used.

This is more efficient, and it lets initremote/enableremote
reject configs that have unknown fields or unparsable values.

It also allows for improved type safety, as shown in
Remote.Helper.Encryptable where things that used to match on string
configs now match on data types.

This is a work in progress, it does not build yet.

The main risk in this conversion is forgetting to add a field to
RemoteConfigParser. That will prevent using that field with
initremote/enableremote, and will prevent remotes that already are set
up from seeing that configuration. So will need to check carefully that
every field that getRemoteConfigValue is called on has been added to
RemoteConfigParser.

(One such case I need to remember is that credPairRemoteField needs to be
included in the RemoteConfigParser.)

add missing backtick

Merge branch 'master' of ssh://git-annex.branchable.com

be stricter about rejecting invalid configurations for remotes

This is a first step toward that goal, using the ProposedAccepted type
in RemoteConfig lets initremote/enableremote reject bad parameters that
were passed in a remote's configuration, while avoiding enableremote
rejecting bad parameters that have already been stored in remote.log

This does not eliminate every place where a remote config is parsed and a
default value is used if the parse false. But, I did fix several
things that expected foo=yes/no and so confusingly accepted foo=true but
treated it like foo=no. There are still some fields that are parsed with
yesNo but not not checked when initializing a remote, and there are other
fields that are parsed in other ways and not checked when initializing a
remote.

This also lays groundwork for rejecting unknown/typoed config keys.

Added a comment: using hardlinks

2020

Added a comment: Summary; Application: shared thumbnails

comment

notes on my recovery from a bad merge

comment

response

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment: git-annex in docker on Windows

fix a transcription error - to disable a remote, we set ignore to true, not false!

Added a comment: WSL 1/2 experience

Added a comment

removed

Added a comment: hi

generalize docs so they will also work when git uses SHA256

response

response

Added a comment: prior research

plan

Merge branch 'master' of ssh://git-annex.branchable.com

use --no-abbrev instead of --abbrev=40

This avoids hardcoding the sha size, so when git uses sha256, it will
output the full sha256 and not a truncation to 40 characters.

I reviewed git's history, and while there have been some
bugs with commands not supporting --no-abbrev (eg git diff --no-index
--no-abbrev was broken in git 2.1), none of the commands git-annex
uses will be impacted by those old bugs.

support sha256 git repos

Git will eventually switch to sha2 and there will not be one single
shaSize anymore, but two (40 and 64).

Changed all parsers for git plumbing output to support both sizes of
shas.

One potential problem this does not deal with is, if somewhere in
git-annex it reads two shas from different sources, and compares them
to see if they're the same sha, it would fail if they're sha1 and sha256
of the same value. I don't know if that will really be a concern.

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

comment

fix typo in close