From f544946b09b0b03a53ebde0a4b8ff5664889ddc2 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 21 May 2024 10:20:30 -0400 Subject: [PATCH] update --- doc/todo/git-remote-annex.mdwn | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/doc/todo/git-remote-annex.mdwn b/doc/todo/git-remote-annex.mdwn index 9099c944f1..37040f0db0 100644 --- a/doc/todo/git-remote-annex.mdwn +++ b/doc/todo/git-remote-annex.mdwn @@ -51,6 +51,7 @@ This is implememented and working. Remaining todo list for it: the last MANIFEST it uploaded, 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 drop those bundle files from the remote. + (May be unsafe, see below section on bundle deletion problems.) * A push race can also appear to the user as if they pushed a ref, but then it got deleted from the remote. This happens when two pushes are @@ -107,4 +108,13 @@ arbitrarily wide. What if only emptying pushes delete bundles? If a manifest file refers to a bundle that has been deleted, that can be treated the same as if the manifest file was empty, because we know that, for that bundle to have been -deleted, there must have been an emptying push. +deleted, there must have been an emptying push. So this would work. + +It is kind of a cop-out, because it requires the user to do an emptying +push from time to time. But by doing that, the user will expect that +someone who pulls at that point gets an empty repository. + +Note that a race between an emptying push an a ref push will result in the +emptying push winning, so the ref push is lost. This is the same behavior +as can happen in a push race not involving deletion though, and any +improvements that are made to the UI around that will also help with this.