mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

prevent using git-remote-annex with unsuitable special remote configs

Browse source 
I hope to support importtree=yes eventually, but it does not currently
work.

Added remote.<name>.allow-encrypted-gitrepo that needs to be set to
allow using it with encrypted git repos.

Note that even encryption=pubkey uses a cipher stored in the git repo
to encrypt the keys stored in the remote. While it would be possible to
not encrypt the GITBUNDLE and GITMANIFEST keys, and then allow using
encryption=pubkey, it doesn't currently work, and that would be a
complication that I doubt is worth it.
This commit is contained in:
Joey Hess 2024-05-14 13:52:20 -04:00
parent 8bf6dab615
commit 6f1039900d
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 63 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

37
doc/todo/git-remote-annex.mdwn
View file

@ -1,5 +1,5 @@
git-remote-annex will be a program that allows push/pull of a git
repository to any git-annex special remote.
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
@ -23,14 +23,20 @@ This is implememented and working. Remaining todo list for it:
* Need to mention git-remote-annex in special remotes page, and perhaps
write a tip for it. Also link to it from git-annex man page.
* initremote could optionally configure the url to a special remote
to an 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`)
* 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.
* Prevent using with remotes that are encrypted using a cipher
stored in the repo. Chicken and egg problem cloning from
such a remote. Maybe allow advanced users to force it?
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`)
* Improve recovery from interrupted push by using outManifest to clean up
after it. (Requires populating outManifest.)
@ -47,18 +53,6 @@ This is implememented and working. Remaining todo list for it:
`datalad-annex::https://example.com?type=web&url={noquery}`
Supporting something like this would be good.
* 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,
and that some, like type=directory, remove some configs
(eg directory=) in their setup action.
* Improve behavior in push races. A race can overwrite a change
to the MANIFEST and lose work that was pushed from the other repo.
From the user's perspective, that situation is the same as if one repo
@ -101,3 +95,4 @@ This is implememented and working. Remaining todo list for it:
Also, when the remote uses importree=yes, pushing to it updates
content identifiers, which currently get recorded in the git-annex
branch. It would be good to avoid that being written as well.