The protocol has `GETCONFIG`, which gives access to the configuration
stored in remote.log, but it does not provide a good way to access git
configs set on the remote.

Datalad uses `GETCONFIG name` to get the remote name, and
then using git config to get its configs. That is suboptimal
because sameas remotes use sameas-name instead, and also because
the two names are not necessarily the same, eg `git remote rename` can
rename the git remote while the git-annex config still uses the other name.
<https://github.com/datalad/datalad/issues/4259>

One way to do that is `GETUUID` and then look for the git remote with
annex-uuid set to that, in order to learn its name and then find its other git
configs. But, it's also possible for there to be multiple git remotes with the
same annex-uuid. (This does not happen with sameas remotes, but like a git repo
can have multiple remotes pointing to it by different paths, the same can be
set up for a special remote, at least in theory.)

So, the protocol should be extended. Either with a way to get/set a single git
config (like `GETCONFIG`/`SETCONFIG` do with the remote.log config), or with a
way to get the git remote name.

The latter has the problem that this business of there being multiple
names for different related things that might be different but are probably
the same is a perhaps not something people want to learn about.

The former seems conceptually simpler, but there might be things that
`git config` could do, that providing an interface on top of it would not
allow. The --type option is one thing that comes to mind. --[[Joey]]

> [[done]] as the GETGITREMOTENAME protocol extension and message.
> --[[Joey]]
