ATM
files didn't datalad push as they should have due to existing settings of wanted:
❯ git annex wanted datasets.datalad.org
include=.datalad/* and (not metadata=distribution-restrictions=*)
❯ git annex find --not --in datasets.datalad.org .
crcns-2022-dataland.pdf
crcns-2022-dataland.png
crcns-2022-dataland.svg
❯ git annex metadata *
metadata crcns-2022-dataland.pdf
ok
metadata crcns-2022-dataland.png
ok
metadata crcns-2022-dataland.svg
ok
❯ git annex copy --auto --to datasets.datalad.org *
❯ git annex version
git-annex version: 10.20231227-1~ndall+1
so I was confused... the reason was
❯ git annex copy --to datasets.datalad.org *
copy crcns-2022-dataland.pdf (to datasets.datalad.org...)
copying to non-ssh repo not supported
failed
copy crcns-2022-dataland.png (to datasets.datalad.org...)
copying to non-ssh repo not supported
failed
copy crcns-2022-dataland.svg (to datasets.datalad.org...)
copying to non-ssh repo not supported
failed
copy: 3 failed
wherever I have
❯ git remote show -n datasets.datalad.org
* remote datasets.datalad.org
Fetch URL: https://datasets.datalad.org/datalad/artwork/.git
Push URL: falkor.dartmouth.edu:/srv/datasets.datalad.org/www/datalad/artwork/.git
...
and the use case is quite common for me and in particular for ReproNim/containers which is shared/adjusted in similar ways
This would not have prevented
copy --autofrom trying to copy the files and failing the same way ascopywithout that option. So I think there must be something in your preferred content that made it skip trying to copy those files.Maybe you meant to have an "or" there? With the and it only wants files that are in .datalad/ as well as not having the metadata set.
As for
pushInsteadOf, in 2011 this was considered in https://bugs.debian.org/644278. And the result was that git-annex honorsinsteadOfbut notpushInsteadOforpushurl. With the (weak?) rationalle that what git-annex does is neither pushing or pulling really.So it seems to me better for you to use
insteadOf. Unless there's some reason why you need git to pull from the http url rather than from the ssh url?Perhaps you're setting this up for many users, some of whom are limited to read-only access. Pulling from http would work for those users. And git-annex get from http also works read-only the way your repository is set up.
If that is the reason you want to use
pushInsteadOfrather thaninsteadOf, it would follow that you would want git-annex to use the pull url for getting files, but use the push url for putting/dropping files.But: If this change were made, it would risk breaking existing working setups, that happen to have a push url that points to a different repository. When git-annex was upgraded to use the push url, it would start noticing that the repository behind the url has a different uuid than the remote does.
For a ssh repository, that would prevent it from using the repository until the user did something to fix the configuration.
For a local repository, git-annex currently automatically updates the cached repository uuid. It's not clear to me how that would work if there were two urls pointing to two different repositories. Does seem like this would prevent eg, getting files from the remote that it was able to get before.
I don't know how common such a setup with a push url pointing to a different repository might be. I think it is much more likely that
remote.foo.pushurlbe pointed to some other url that is not on the same server. pushInsteadOf is really intended to configure a different access method for the same server as the repository url.