This commit is contained in:
Joey Hess 2024-02-02 14:32:12 -04:00
parent 5621922e08
commit fc32632774
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 64 additions and 0 deletions

View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2024-02-02T17:23:13Z"
content="""
This would not have prevented `copy --auto` from trying to copy the files
and failing the same way as `copy` without that option. So I think there
must be something in your preferred content that made it skip trying to
copy those files.
include=.datalad/* and (not metadata=distribution-restrictions=*)
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.
"""]]

View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2024-02-02T17:25:54Z"
content="""
As for `pushInsteadOf`, in 2011 this was considered
in <https://bugs.debian.org/644278>. And the result was that git-annex
honors `insteadOf` but not `pushInsteadOf` or `pushurl`. 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 `pushInsteadOf` rather than
`insteadOf`, 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.
"""]]

View file

@ -0,0 +1,25 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2024-02-02T17:57:51Z"
content="""
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.pushurl` be 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.
"""]]