Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

Re: [PATCH 10/15] refs.c: allow multiple reflog updates during a single transaction

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:02:46

Ronnie Sahlberg [off-list ref] writes:
quoted hunk
@@ -3531,7 +3537,7 @@ struct ref_update {
 	enum transaction_update_type update_type;
 	unsigned char new_sha1[20];
 	unsigned char old_sha1[20];
-	int flags; /* REF_NODEREF? */
+	int flags; /* REF_NODEREF? or private flags */
Not a very informative comment, I'd have to say.  How are users of
this API expected to avoid stepping on each others' and API
implementation's toes?
quoted hunk
@@ -3539,8 +3545,9 @@ struct ref_update {
 
 	/* used by reflog updates */
 	int reflog_fd;
-	struct lock_file reflog_lock;
+	struct lock_file *reflog_lock;
What is this change about?

Does the lifetime rule for "struct lock_file" described in
Documentation/technical/api-lockfile.txt, namely, "once you call
hold_lock_file_* family on it, you cannot free it yourself", have
any implication on this?
+	if (!(update->flags & UPDATE_REFLOG_NOLOCK))
+		update->reflog_lock = xcalloc(1, sizeof(struct lock_file));
+
Hmph, does this mean that the caller needs to keep track of the refs
it ever touched inside a single transaction, call this without nolock
on the first invocation on a particular ref and with nolock on the
subsequent invocation?

Or is the "caller" just implementation detail of the API and higher level
callers do not have to care?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help