From: Ævar Arnfjörð Bjarmason Date: Fri, 16 Jul 2021 14:13:04 GMT Subject: [PATCH v2 08/11] refs/files: add a comment about refs_reflog_exists() call Message-ID: In-Reply-To: Add a comment about why it is that we need to check for the the existence of a reflog we're deleting after we've successfully acquired the lock in files_reflog_expire(). As noted in [1] the lock protocol for reflogs is somewhat intuitive. This early exit code the comment applies to dates all the way back to 4264dc15e19 (git reflog expire, 2006-12-19). 1. https://lore.kernel.org/git/54DCDA42.2060800@alum.mit.edu/ Signed-off-by: Ævar Arnfjörð Bjarmason --- refs/files-backend.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/refs/files-backend.c b/refs/files-backend.c index ec9c70d79cc..f73637fa087 100644 --- a/refs/files-backend.c +++ b/refs/files-backend.c @@ -3068,6 +3068,17 @@ static int files_reflog_expire(struct ref_store *ref_store, strbuf_release(&err); return -1; } + + /* + * When refs are deleted their reflog is deleted before the + * ref itself deleted. This race happens because there's no + * such thing as a lock on the reflog, instead we always lock + * the "loose ref" (even if packet) above with + * lock_ref_oid_basic(). + * + * If race happens we've got nothing more to do, we were asked + * to delete the reflog, and it's not there anymore. Great! + */ if (!refs_reflog_exists(ref_store, refname)) { unlock_ref(lock); return 0; -- 2.32.0.873.gb6f2f696497