0be9f7a2c6
The UUID is included in the GITMANIFEST in order to allow a single key/value store to be used to store several special remotes, without any namespacing. In that situation though, if the same ref is pushed to two special remotes, it will result in git bundles with the same content. Which is ok, until a re-push happens to one of the special remote. At that point, the old git bundle will be deleted. That will prevent fetching it from the other special remote, where the re-push has not happened. Adding the UUID avoids this problem.
52 lines
1.7 KiB
Markdown
52 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.
|
|
|
|
# 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.
|