git-remote-annex support exporttree=yes remotes
Put the annex objects in .git/annex/objects/ inside the export remote. This way, when importing from the remote, they will be filtered out. Note that, when importtree=yes, content identifiers are used, and this means that pushing to a remote updates the git-annex branch. Urk. Will need to try to prevent that later, but I already had a todo about that for other reasons. Untested! Sponsored-By: Brock Spratlen on Patreon
This commit is contained in:
parent
3f848564ac
commit
34eae54ff9
4 changed files with 151 additions and 47 deletions
|
@ -18,6 +18,11 @@ and are in the process of being deleted.
|
|||
|
||||
(Lines end with unix `"\n"`, not `"\r\n"`.)
|
||||
|
||||
# exporttree=yes remotes
|
||||
|
||||
In an exporttree=yes remote, the GITMANIFEST and GITBUNDLE objects are
|
||||
stored in the remote, under the `.git/annex/objects/` path.
|
||||
|
||||
# multiple GITMANIFEST files
|
||||
|
||||
Usually there will only be one per special remote, but it's possible for
|
||||
|
@ -38,6 +43,6 @@ stored in such a special remote, this procedure will work:
|
|||
(Note that later bundles can update refs from the versions in previous
|
||||
bundles.)
|
||||
|
||||
When the special remote is encryptee, the GITMANIFEST and GITBUNDLE will
|
||||
When the special remote is encrypted, the GITMANIFEST and GITBUNDLE will
|
||||
also be encrypted. To decrypt those manually, see this
|
||||
[[fairly simple shell script using standard tools|tips/Decrypting_files_in_special_remotes_without_git-annex]].
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue