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

guard pushEmpty

Browse source
This commit is contained in:
Joey Hess 2024-05-21 12:09:45 -04:00
parent 969da25d66
commit 10a60183e1
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 8 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
CmdLine/GitRemoteAnnex.hs
View file

@ -351,7 +351,7 @@ incrementalPush st rmt oldtrackingrefs newtrackingrefs = guardPush st $ do
)
pushEmpty :: State -> Remote -> Annex (Bool, State)
pushEmpty st rmt = do
pushEmpty st rmt = guardPush st $ do
oldmanifest <- maybe (downloadManifestWhenPresent rmt) pure
(manifestCache st)
let manifest = mkManifest mempty

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

@ -42,9 +42,12 @@ This is implememented and working. Remaining todo list for it:
Could git-annex detect this after the fact and clean it up? Eg,
if it caches the last manifest it uploaded, the next time it downloads
the manifest it can check if there are bundle files in the old
one that are not in the new one. If so, it can add those to the
outManifest, to get dropped later.
the manifest it can check if there are bundle files in the cached
manifest that are not in the new one, that still exist in the remote.
If so, it can add those to the outManifest, to get dropped later.
This wouldn't fix the case where a push race happens and then the repo
whose manifest was overwritten gets deleted.
whose manifest was overwritten gets deleted. But this is similar to
adding a file to the annex, copying it to the special remote, and then
deleting the repo w/o sending the git-annex branch anywhere, which leaves
a dangling object too. So don't worry about that.