Thread (2 messages) flat view 2 messages, 2 authors, 2021-07-19

Re: [PATCH v2 06/11] refs API: pass the "lock OID" to reflog "prepare"

From: Junio C Hamano <hidden>
Date: 2021-07-19 16:43:28

Ævar Arnfjörð Bjarmason  [off-list ref] writes:
Don't pass the object ID we pass into reflog_expire() back to the
caller, but rather our locked OID.

As the assert shows these two were the same thing in practice as we'd
It is unclear which assert you refer to, but a call to verify_lock()
near the end of lock_ref_oid_basic() ensures this, I presume?
exit earlier in this function if we couldn't lock the desired OID, but
as part of removing the passing of the OID to other functions further
on I'm splitting up these concerns.

As we'll see in a subsequent commit we don't actually want to assert
that we locked a given OID, we want this API to do the locking and
tell us what the OID is, but for now let's just setup the scaffolding
for that.
OK.  That sounds like a sensible direction to go in.
quoted hunk
diff --git a/refs/files-backend.c b/refs/files-backend.c
index af332fa8fe4..ec9c70d79cc 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -3098,7 +3098,7 @@ static int files_reflog_expire(struct ref_store *ref_store,
 		}
 	}
 
-	(*prepare_fn)(refname, oid, cb.policy_cb);
+	(*prepare_fn)(refname, &lock->old_oid, cb.policy_cb);
 	refs_for_each_reflog_ent(ref_store, refname, expire_reflog_ent, &cb);
 	(*cleanup_fn)(cb.policy_cb);
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help