mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

improve recovery from interrupted push

Browse source 
On push, first try to drop all outManifest keys listed in the current
manifest file, which resumes from an interrupted push that didn't
get a chance to delete those keys.

The new manifest gets its outManifest populated with the keys that were
in the old manifest, plus any of the keys that were unable to be
dropped.

Note that it would be possible for uploadManifest to skip dropping old
keys at all. The old keys would get dropped on the next push. But it
seems better to delete stuff immediately rather than waiting. And the
extra work is limited to push and typically is small.

A remote where dropKey always fails will result in an outManifest that
grows longer and longer. It would be possible to check if the remote
has appendonly = True and avoid populating the outManifest. Of course,
an appendonly remote will grow with every git push anyway. And currently
only Remote.GitLFS sets that, which can't be used as a git-remote-annex
remote anyway.
This commit is contained in:
Joey Hess 2024-05-20 13:49:45 -04:00
parent 4ce70533e9
commit 34a6db4f15
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 36 additions and 32 deletions
Download patch file Download diff file Expand all files Collapse all files

5
doc/todo/git-remote-annex.mdwn
View file

@ -31,10 +31,7 @@ This is implememented and working. Remaining todo list for it:
* Cloning from an annex:: url with importtree=yes doesn't work
(with or without exporttree=yes). This is because the ContentIdentifier
db is not populated.
* Improve recovery from interrupted push by using outManifest to clean up
after it. (Requires populating outManifest.)
db is not populated. It should be possible to work around this.
* See XXX in uploadManifest about recovering from a situation
where the remote is left with a deleted manifest when a push