c7731cdbd9
Making GITBUNDLE be in the backend list allows those keys to be hashed to verify, both when git-remote-annex downloads them, and by other transfers and by git fsck. GITMANIFEST is not in the backend list, because those keys will never be stored in .git/annex/objects and can't be verified in any case. This does mean that git-annex version will include GITBUNDLE in the list of backends. Also documented these in backends.mdwn Sponsored-by: Kevin Mueller on Patreon
54 lines
1.7 KiB
Markdown
54 lines
1.7 KiB
Markdown
This adds two new key types to git-annex, GITMANIFEST and a GITBUNDLE.
|
|
|
|
GITMANIFEST--$UUID is the manifest for a git repository stored in the
|
|
git-annex repository with that UUID.
|
|
|
|
GITBUNDLE--$UUID-sha256 is a git bundle.
|
|
|
|
# format of the manifest file
|
|
|
|
An ordered list of bundle keys, one per line.
|
|
|
|
(Lines end with unix `"\n"`, not `"\r\n"`.)
|
|
|
|
# fetching
|
|
|
|
1. download GITMANIFEST for the uuid of the special remote
|
|
2. download each listed GITBUNDLE key that we don't have
|
|
3. `git fetch` from each new bundle in order
|
|
(note that later bundles can update refs from the versions in previous
|
|
bundles)
|
|
|
|
# pushing (incrementally)
|
|
|
|
This is how pushes are usually done.
|
|
|
|
1. create git bundle of all refs that are being pushed and have changed,
|
|
and objects since the previously pushed refs
|
|
2. hash to calculate GITBUNDLE key
|
|
3. upload GITBUNDLE key
|
|
4. download current manifest
|
|
5. append GITBUNDLE key to manifest
|
|
|
|
# pushing (full)
|
|
|
|
Note that this can be used to replace incrementals with a single bundle for
|
|
performance. It is also the only way to handle a push that deletes a
|
|
previously pushed ref.
|
|
|
|
1. create git bundle containing all refs stored in the repository, and all
|
|
objects
|
|
2. hash to calculate GITBUNDLE key name
|
|
3. upload GITBUNDLE key
|
|
4. download old manifest
|
|
4. upload new manifest listing only the single new GITBUNDLE
|
|
5. delete all other GITBUNDLEs that were listed in the old manifest
|
|
|
|
# multiple GITMANIFEST files
|
|
|
|
Usually there will only be one per special remote, but it's possible for
|
|
multiple special remotes to point to the same object storage, and if so
|
|
multiple GITMANIFEST objects can be stored.
|
|
|
|
It follows that the UUID of the special remote has to be included in the
|
|
annex:// uri, to know which GITMANIFEST to use when cloning from it.
|