based on mih filing or commenting on things and/or on
git-remote-annex being used
This commit is contained in:
Joey Hess 2025-01-07 15:52:20 -04:00
parent f13819cde0
commit dcc259f940
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 7 additions and 0 deletions

View file

@ -130,3 +130,4 @@ And here is the diff between the two sequences (failure(-) vs success(+)
This observation comes from an effort to implement a git-remote-helper that uses git-annex to enable fetch/push to and from any location that can be reached by any special remote. The fact that git-annex can be used to build things like this is just crazy cool! Thx much!
[[!tag projects/datalad]]
[[!tag projects/INM7]]

View file

@ -496,3 +496,5 @@ backups, where it gives structure to my image-based backup routines, so you coul
say I'm a believer. :)
[[!meta author=jkniiv]]
[[!tag projects/INM7]]

View file

@ -5,3 +5,5 @@ A use case not possible with that approach is *authenticated* read-only access.
Weighing the two approaches (read-only `webdav` vs authenticated `httpalso`), it appears that only the read-only `webdav` is compatible with [git-remote-annex](https://git-annex.branchable.com/git-remote-annex/), because a user would need to declare *one* special remote (configuration) to use for cloning.
It would be great to have authenticated, read-only access to webdav shares. Thanks in advance for considering!
[[!tag projects/INM7]]

View file

@ -60,3 +60,5 @@ I believe that no particular handling of annex key that are declared inputs to c
### Trust
We would need a way for users to indicate that they trust a particular compute introduction or the entity that provided it. Even if git-annex does not implement tooling for that, it would be good to settle on a concept that can be interpreted/implemented by such special remotes.
[[!tag projects/INM7]]