483887591d
Not quite there yet. Also, changed the format of GITBUNDLE keys to use only one '-' after the UUID. A sha256 does not contain that character, so can just split at the last one. Amusingly, the sha256 will probably not actually be verified. A git bundle contains its own checksums that git uses to verify it. And if someone wanted to replace the content of a GITBUNDLE object, they could just edit the manifest to use a new one whose sha256 does verify. Sponsored-by: Nicholas Golder-Manning
54 lines
1.7 KiB
Markdown
54 lines
1.7 KiB
Markdown
This adds two new object 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 object 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 object
|
|
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 object name
|
|
3. upload GITBUNDLE object
|
|
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.
|