git-remote-annex will be a program that allows push/pull/clone of a git
repository to many types of git-annex special remote.

This is a redesign and reimplementation of git-remote-datalad-annex. 
It will be a safer implementation, will support incremental pushes, and
will be available to users who don't use datalad. 
--[[Joey]]

---

This is implememented and working. Remaining todo list for it:

* Test incremental push edge cases involving checkprereq.

* Cloning from an annex:: url with importtree=yes doesn't work
  (with or without exporttree=yes). This is because the ContentIdentifier
  db is not populated. It should be possible to work around this.

* It would be nice if git-annex could generate an annex:: url
  for a special remote and show it to the user, eg when 
  they have set the shorthand "annex::" url, so they know the full url.
  `git-annex info $remote` could also display it.
  Currently, the user has to remember how the special remote was
  configured and replicate it all in the url.

  There are some difficulties to doing this, including that
  RemoteConfig can have hidden fields that should be omitted.

* initremote/enableremote could have an option that configures the url to a
  special remote to a annex:: url. This would make it easier to use
  git-remote-annex, since the user would not need to set up the url
  themselves. (Also it would then avoid setting `skipFetchAll = true`)

* datalad-annex supports cloning from the web special remote,
  using an url that contains the result of pushing to eg, a directory
  special remote.
  `datalad-annex::https://example.com?type=web&url={noquery}`
  Supporting something like this would be good.

* A push race can overwrite a manifest that had a GITBUNDLE added to it,
  and so lose track of a GITBUNDLE. That will never get deleted.

  Could git-annex detect this after the fact and clean it up? Eg,
  if it caches the last manifest it uploaded, the next time it downloads
  the manifest it can check if there are bundle files in the old
  one that are not in the new one. If so, it can add those to the
  outManifest, to get dropped later.

  This wouldn't fix the case where a push race happens and then the repo
  whose manifest was overwritten gets deleted.