Thread (65 messages) flat view 65 messages, 3 authors, 2021-08-23
STALE1856d

Revision v5 of 4 in this series.

Revisions (4)
  1. v2 [diff vs current]
  2. v3 [diff vs current]
  3. v4 [diff vs current]
  4. v5 current

[PATCH v5 08/13] refs/files: add a comment about refs_reflog_exists() call

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-08-23 11:36:31
Subsystem: the rest · Maintainer: Linus Torvalds

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/ (local)

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
 refs/files-backend.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 997e021c1c4..fbcd0c790bc 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -3061,6 +3061,19 @@ 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 is deleted. This is because there is no separate
+	 * lock for reflog; instead we take a lock on the ref with
+	 * lock_ref_oid_basic().
+	 *
+	 * If a race happens and the reflog doesn't exist after we've
+	 * acquired the lock that's OK. We've got nothing more to do;
+	 * We were asked to delete the reflog, but someone else
+	 * deleted it! The caller doesn't care that we deleted it,
+	 * just that it is deleted. So we can return successfully.
+	 */
 	if (!refs_reflog_exists(ref_store, refname)) {
 		unlock_ref(lock);
 		return 0;
-- 
2.33.0.662.g438caf9576d
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help