Re: [PATCH] refs: run copy and rename through transactions

Junio C Hamano [off-list ref] writes:

quoted

+struct files_copy_or_rename_transaction_data {
+	struct ref_lock *lock;
+	struct object_id orig_oid;
+	struct object_id destination_oid;
+	char *destination_target;
+	int logmoved;
+	int destination_exists;
+	int destination_log_backed_up;
+};

Good to have a type that can be used to hold pieces of information
specific to the operation.  Can't we do without rename/copy specific
addition to the generic ref_transaction struct by following the same
principle?

The comment above the members does make it understandable, but ...

quoted

@@ -240,6 +253,21 @@ struct ref_transaction {
 	void *backend_data;
 	unsigned int flags;
 	uint64_t max_index;
+
+	/*
+	 * Rename and copy operations need backend-specific reflog handling.
+	 * Their logical updates still live in `updates`, so hooks see the
+	 * operation like any other reference transaction. The fields below
+	 * retain the state that backends verify after taking their locks.
+	 */
+	enum ref_transaction_type type;
+	char *old_refname;
+	char *new_refname;
+	char *logmsg;
+	struct object_id source_oid;
+	struct object_id destination_oid;
+	char *destination_target;
+	unsigned int destination_exists:1;
 };

... is it the best we can do to contaminate a rather generic data
structure for such a details relevant only to one specific
operation?

More importantly, this structure suggests to me that you can have a
single rename (or copy) from one source to one destination in a
single transaction.  Is that correct or am I misunderstanding the
way this data structure is used?  How would one rename A, B and C
to X, Y and Z in a single transaction?  Or perhaps rename A to B
and copy C to D in a single transaction?