followup
This commit is contained in:
parent
5621922e08
commit
fc32632774
3 changed files with 64 additions and 0 deletions
|
@ -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.
|
||||||
|
"""]]
|
|
@ -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.
|
||||||
|
"""]]
|
|
@ -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.
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue