From: Junio C Hamano <gitster@pobox.com>
To: Maciej Ciemborowicz <maciej.ciemborowicz@gmail.com>
Cc: git@vger.kernel.org, Karthik Nayak <karthik.188@gmail.com>
Subject: Re: [PATCH] refs: run copy and rename through transactions
Date: Mon, 21 Sep 2026 16:28:28 -0700 [thread overview]
Message-ID: <xmqqh5jijiar.fsf@gitster.g> (raw)
In-Reply-To: <xmqqjyoemqvu.fsf@gitster.g> (Junio C. Hamano's message of "Mon, 21 Sep 2026 10:54:45 -0700")
Junio C Hamano <gitster@pobox.com> writes:
>> +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 ...
>
>> @@ -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?
next prev parent reply other threads:[~2026-09-21 23:28 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-19 13:33 [BUG] reference-transaction hook misses destination of git branch -m Maciej Ciemborowicz
2026-09-19 20:52 ` Karthik Nayak
2026-09-20 16:50 ` [PATCH] refs: run copy and rename through transactions Maciej Ciemborowicz
2026-09-21 17:54 ` Junio C Hamano
2026-09-21 23:28 ` Junio C Hamano [this message]
2026-09-22 13:08 ` Maciej Ciemborowicz
2026-09-23 13:36 ` [PATCH v2] " Maciej Ciemborowicz
2026-09-30 3:32 ` Maciej Ciemborowicz
2026-10-02 10:56 ` Patrick Steinhardt
2026-10-02 14:16 ` Maciej Ciemborowicz
2026-10-05 6:03 ` Patrick Steinhardt
2026-10-07 18:05 ` [PATCH v3 0/4] " Maciej Ciemborowicz
2026-10-07 18:05 ` [PATCH v3 1/4] refs: distinguish internal transactions from logical updates Maciej Ciemborowicz
2026-10-07 18:05 ` [PATCH v3 2/4] refs: support replacing reflogs in a transaction Maciej Ciemborowicz
2026-10-07 18:05 ` [PATCH v3 3/4] refs: run copy and rename through ordinary transactions Maciej Ciemborowicz
2026-10-07 18:05 ` [PATCH v3 4/4] refs: remove backend-specific copy and rename callbacks Maciej Ciemborowicz
2026-10-07 19:55 ` [PATCH v3 0/4] refs: run copy and rename through transactions Junio C Hamano
2026-10-08 9:44 ` [PATCH v4 " Maciej Ciemborowicz
2026-10-08 9:44 ` [PATCH v4 1/4] refs: distinguish internal transactions from logical updates Maciej Ciemborowicz
2026-10-08 9:44 ` [PATCH v4 2/4] refs: support replacing reflogs in a transaction Maciej Ciemborowicz
2026-10-08 9:44 ` [PATCH v4 3/4] refs: run copy and rename through ordinary transactions Maciej Ciemborowicz
2026-10-08 9:44 ` [PATCH v4 4/4] refs: remove backend-specific copy and rename callbacks Maciej Ciemborowicz
2026-10-08 10:10 ` [PATCH v4 0/4] refs: run copy and rename through transactions Patrick Steinhardt
2026-10-08 10:43 ` Maciej Ciemborowicz
2026-10-08 11:01 ` Maciej Ciemborowicz
2026-10-08 15:45 ` Junio C Hamano
2026-10-08 19:06 ` Maciej Ciemborowicz
2026-10-08 19:19 ` Kristoffer Haugsbakk
2026-10-08 21:11 ` Maciej Ciemborowicz
2026-10-09 5:41 ` Patrick Steinhardt
2026-10-10 0:22 ` brian m. carlson
2026-10-08 15:54 ` Junio C Hamano
2026-10-09 21:21 ` Karthik Nayak
2026-10-10 0:06 ` Maciej Ciemborowicz
2026-09-23 12:49 ` [PATCH v4 0/3] refs: report old OIDs for batched deletions Maciej Ciemborowicz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh5jijiar.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.com \
--cc=maciej.ciemborowicz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.