avoid interrupted push leaving remote without a manifest

Added a backup manifest key, which is used if the main manifest key is
not present. When uploading a new Manifest, it makes sure that it never
drops one key except when the other key is present.

It's entirely possible for the two manifest keys to get out of sync, due
to races. The main one wins when it's present, it is possible for the
main one being dropped to expose the backup one, which has a different
push recorded.
This commit is contained in:
Joey Hess 2024-05-20 15:41:09 -04:00
parent 594ca2fd3a
commit 3a38520aac
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 67 additions and 67 deletions

View file

@ -4,9 +4,10 @@ repository to a special remote, and later cloning from it.
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.
git-annex repository with that UUID. When that is not present,
GITMANIFEST--$UUID.bak is a backup copy that can be used instead.
GITBUNDLE--$UUID-sha256 is a git bundle.
GITBUNDLE--$UUID-$sha256 is a git bundle.
# format of the manifest file
@ -23,11 +24,10 @@ and are in the process of being deleted.
In an exporttree=yes remote, the GITMANIFEST and GITBUNDLE objects are
stored in the remote, under the `.git/annex/objects/` path.
# multiple GITMANIFEST files
# multiple special remotes in the same place
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's possible for multiple special remotes to point to the same
object storage.
This is why the UUID of the special remote is included in the GITMANIFEST
key, and in the annex:: uri.