git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Toon Claes <toon@iotcl.com>
To: Karthik Nayak <karthik.188@gmail.com>, git@vger.kernel.org
Cc: Karthik Nayak <karthik.188@gmail.com>,
	ps@pks.im, Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH v4 7/8] refs: allow multiple reflog entries for the same refname
Date: Thu, 19 Dec 2024 20:33:17 +0100	[thread overview]
Message-ID: <871py3h3ia.fsf@iotcl.com> (raw)
In-Reply-To: <20241216-320-git-refs-migrate-reflogs-v4-7-d7cd3f197453@gmail.com>

Karthik Nayak <karthik.188@gmail.com> writes:

> The reference transaction only allows a single update for a given
> reference to avoid conflicts. This, however, isn't an issue for reflogs.
> There are no conflicts to be resolved in reflogs and when migrating
> reflogs between backends we'd have multiple reflog entries for the same
> refname.
>
> So allow multiple reflog updates within a single transaction. Also the
> reflog creation logic isn't exposed to the end user. While this might
> change in the future, currently, this reduces the scope of issues to
> think about.
>
> In the reftable backend, the writer sorts all updates based on the
> update_index before writing to the block. When there are multiple
> reflogs for a given refname, it is essential that the order of the
> reflogs is maintained. So add the `index` value to the `update_index`.
> The `index` field is only set when multiple reflog entries for a given
> refname are added and as such in most scenarios the old behavior
> remains.
>
> This is required to add reflog migration support to `git refs migrate`.
>
> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> ---
>  refs/files-backend.c    | 15 +++++++++++----
>  refs/reftable-backend.c | 22 +++++++++++++++++++---
>  2 files changed, 30 insertions(+), 7 deletions(-)
>
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index c11213f52065bcf2fa7612df8f9500692ee2d02c..8953d1c6d37b13b0db701888b3db92fd87a68aaa 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -2611,6 +2611,9 @@ static int lock_ref_for_update(struct files_ref_store *refs,
>  
>  	update->backend_data = lock;
>  
> +	if (update->flags & REF_LOG_ONLY)
> +		goto out;
> +
>  	if (update->type & REF_ISSYMREF) {
>  		if (update->flags & REF_NO_DEREF) {
>  			/*
> @@ -2829,13 +2832,16 @@ static int files_transaction_prepare(struct ref_store *ref_store,
>  	 */
>  	for (i = 0; i < transaction->nr; i++) {
>  		struct ref_update *update = transaction->updates[i];
> -		struct string_list_item *item =
> -			string_list_append(&affected_refnames, update->refname);
> +		struct string_list_item *item;
>  
>  		if ((update->flags & REF_IS_PRUNING) &&
>  		    !(update->flags & REF_NO_DEREF))
>  			BUG("REF_IS_PRUNING set without REF_NO_DEREF");
>  
> +		if (update->flags & REF_LOG_ONLY)
> +			continue;
> +
> +		item = string_list_append(&affected_refnames, update->refname);
>  		/*
>  		 * We store a pointer to update in item->util, but at
>  		 * the moment we never use the value of this field
> @@ -3035,8 +3041,9 @@ static int files_transaction_finish_initial(struct files_ref_store *refs,
>  
>  	/* Fail if a refname appears more than once in the transaction: */
>  	for (i = 0; i < transaction->nr; i++)
> -		string_list_append(&affected_refnames,
> -				   transaction->updates[i]->refname);
> +		if (!(transaction->updates[i]->flags & REF_LOG_ONLY))
> +			string_list_append(&affected_refnames,
> +					   transaction->updates[i]->refname);
>  	string_list_sort(&affected_refnames);
>  	if (ref_update_reject_duplicates(&affected_refnames, err)) {
>  		ret = TRANSACTION_GENERIC_ERROR;
> diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
> index b2e3ba877de9e59fea5a4d066eb13e60ef22a32b..bec5962debea7b62572d08f6fa8fd38ab4cd8af6 100644
> --- a/refs/reftable-backend.c
> +++ b/refs/reftable-backend.c
> @@ -990,8 +990,9 @@ static int reftable_be_transaction_prepare(struct ref_store *ref_store,
>  		if (ret)
>  			goto done;
>  
> -		string_list_append(&affected_refnames,
> -				   transaction->updates[i]->refname);
> +		if (!(transaction->updates[i]->flags & REF_LOG_ONLY))
> +			string_list_append(&affected_refnames,
> +					   transaction->updates[i]->refname);
>  	}
>  
>  	/*
> @@ -1301,6 +1302,7 @@ static int write_transaction_table(struct reftable_writer *writer, void *cb_data
>  	struct reftable_log_record *logs = NULL;
>  	struct ident_split committer_ident = {0};
>  	size_t logs_nr = 0, logs_alloc = 0, i;
> +	uint64_t max_update_index = ts;
>  	const char *committer_info;
>  	int ret = 0;
>  
> @@ -1405,7 +1407,19 @@ static int write_transaction_table(struct reftable_writer *writer, void *cb_data
>  				}
>  
>  				fill_reftable_log_record(log, &c);
> -				log->update_index = ts;
> +
> +				/*
> +				 * Updates are sorted by the writer. So updates for the same
> +				 * refname need to contain different update indices.
> +				 */
> +				log->update_index = ts + u->index;

During my review I was having a hard time figuring out when `u->index`
was not 0 and where it is being set. Can you maybe explain a bit?

> +
> +				/*
> +				 * Note the max update_index so the limit can be set later on.
> +				 */
> +				if (log->update_index > max_update_index)

Is there a lot of value in having this if clause? I was a bit confused
why it is here, because I think we can do the assignment to
max_update_index unconditionally.

> +					max_update_index = log->update_index;
> +
>  				log->refname = xstrdup(u->refname);
>  				memcpy(log->value.update.new_hash,
>  				       u->new_oid.hash, GIT_MAX_RAWSZ);
> @@ -1469,6 +1483,8 @@ static int write_transaction_table(struct reftable_writer *writer, void *cb_data
>  	 * and log blocks.
>  	 */
>  	if (logs) {
> +		reftable_writer_set_limits(writer, ts, max_update_index);

So max_update_index is used to set the limits on the current writer, but
using reftable_stack_next_update_index() it's also used to give the next
stack it's starting point for their range. Now I'm not familiar enough
with the code, but are all stacks handled in sequential order? And how
does a stack relate to a reftable file?

> +
>  		ret = reftable_writer_add_logs(writer, logs, logs_nr);
>  		if (ret < 0)
>  			goto done;
>
> -- 
> 2.47.1

  reply	other threads:[~2024-12-19 19:33 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-09 11:07 [PATCH 0/7] refs: add reflog support to `git refs migrate` Karthik Nayak
2024-12-09 11:07 ` [PATCH 1/7] refs: include committer info in `ref_update` struct Karthik Nayak
2024-12-10 16:51   ` Christian Couder
2024-12-11 10:13     ` karthik nayak
2024-12-09 11:07 ` [PATCH 2/7] refs: add `index` field to `struct ref_udpate` Karthik Nayak
2024-12-09 11:07 ` [PATCH 3/7] refs/files: add count field to ref_lock Karthik Nayak
2024-12-10 17:22   ` Christian Couder
2024-12-11 10:18     ` karthik nayak
2024-12-11  9:05   ` Christian Couder
2024-12-11 10:26     ` karthik nayak
2024-12-09 11:07 ` [PATCH 4/7] refs: extract out refname verification in transactions Karthik Nayak
2024-12-11  9:26   ` Christian Couder
2024-12-11 10:31     ` karthik nayak
2024-12-11 14:26     ` Patrick Steinhardt
2024-12-09 11:07 ` [PATCH 5/7] refs: introduce the `ref_transaction_update_reflog` function Karthik Nayak
2024-12-11 10:10   ` Christian Couder
2024-12-11 18:06     ` karthik nayak
2024-12-11 14:26   ` Patrick Steinhardt
2024-12-11 18:09     ` karthik nayak
2024-12-09 11:07 ` [PATCH 6/7] refs: allow multiple reflog entries for the same refname Karthik Nayak
2024-12-11 10:44   ` Christian Couder
2024-12-12 14:52     ` karthik nayak
2024-12-11 14:26   ` Patrick Steinhardt
2024-12-12 14:47     ` karthik nayak
2024-12-09 11:07 ` [PATCH 7/7] refs: add support for migrating reflogs Karthik Nayak
2024-12-11 14:26   ` Patrick Steinhardt
2024-12-12 14:04     ` karthik nayak
2024-12-10 12:13 ` [PATCH 0/7] refs: add reflog support to `git refs migrate` Junio C Hamano
2024-12-10 17:42   ` karthik nayak
2024-12-10 18:03     ` karthik nayak
2024-12-13 10:36 ` [PATCH v2 0/8] " Karthik Nayak
2024-12-13 10:36   ` [PATCH v2 1/8] refs: include committer info in `ref_update` struct Karthik Nayak
2024-12-13 10:36   ` [PATCH v2 2/8] refs: add `index` field to `struct ref_udpate` Karthik Nayak
2024-12-13 10:36   ` [PATCH v2 3/8] refs/files: add count field to ref_lock Karthik Nayak
2024-12-13 10:36   ` [PATCH v2 4/8] refs: extract out refname verification in transactions Karthik Nayak
2024-12-13 10:36   ` [PATCH v2 5/8] refs: add `committer_info` to `ref_transaction_add_update()` Karthik Nayak
2024-12-13 12:24     ` Patrick Steinhardt
2024-12-13 19:43       ` karthik nayak
2024-12-19 19:31         ` Toon Claes
2024-12-20 11:31           ` karthik nayak
2024-12-13 10:36   ` [PATCH v2 6/8] refs: introduce the `ref_transaction_update_reflog` function Karthik Nayak
2024-12-13 11:44     ` Christian Couder
2024-12-13 19:49       ` karthik nayak
2024-12-13 12:24     ` Patrick Steinhardt
2024-12-13 10:36   ` [PATCH v2 7/8] refs: allow multiple reflog entries for the same refname Karthik Nayak
2024-12-13 12:24     ` Patrick Steinhardt
2024-12-13 20:02       ` karthik nayak
2024-12-13 10:36   ` [PATCH v2 8/8] refs: add support for migrating reflogs Karthik Nayak
2024-12-13 12:24     ` Patrick Steinhardt
2024-12-15 11:09       ` karthik nayak
2024-12-15 16:25   ` [PATCH v3 0/8] refs: add reflog support to `git refs migrate` Karthik Nayak
2024-12-15 16:25     ` [PATCH v3 1/8] refs: include committer info in `ref_update` struct Karthik Nayak
2024-12-15 16:25     ` [PATCH v3 2/8] refs: add `index` field to `struct ref_udpate` Karthik Nayak
2024-12-15 16:25     ` [PATCH v3 3/8] refs/files: add count field to ref_lock Karthik Nayak
2024-12-15 16:25     ` [PATCH v3 4/8] refs: extract out refname verification in transactions Karthik Nayak
2024-12-15 16:25     ` [PATCH v3 5/8] refs: add `committer_info` to `ref_transaction_add_update()` Karthik Nayak
2024-12-15 16:25     ` [PATCH v3 6/8] refs: introduce the `ref_transaction_update_reflog` function Karthik Nayak
2024-12-15 16:25     ` [PATCH v3 7/8] refs: allow multiple reflog entries for the same refname Karthik Nayak
2024-12-15 16:25     ` [PATCH v3 8/8] refs: add support for migrating reflogs Karthik Nayak
2024-12-16  7:25       ` Patrick Steinhardt
2024-12-16 15:50         ` Junio C Hamano
2024-12-16 15:59           ` karthik nayak
2024-12-15 23:54     ` [PATCH v3 0/8] refs: add reflog support to `git refs migrate` Junio C Hamano
2024-12-16 14:33       ` karthik nayak
2024-12-16 16:32         ` Junio C Hamano
2024-12-16 16:44     ` [PATCH v4 " Karthik Nayak
2024-12-16 16:44       ` [PATCH v4 1/8] refs: include committer info in `ref_update` struct Karthik Nayak
2024-12-16 16:44       ` [PATCH v4 2/8] refs: add `index` field to `struct ref_udpate` Karthik Nayak
2024-12-19 19:28         ` Toon Claes
2024-12-20 10:09           ` karthik nayak
2024-12-16 16:44       ` [PATCH v4 3/8] refs/files: add count field to ref_lock Karthik Nayak
2024-12-16 16:44       ` [PATCH v4 4/8] refs: extract out refname verification in transactions Karthik Nayak
2024-12-19 19:29         ` Toon Claes
2024-12-20 10:30           ` karthik nayak
2024-12-16 16:44       ` [PATCH v4 5/8] refs: add `committer_info` to `ref_transaction_add_update()` Karthik Nayak
2024-12-19 19:30         ` Toon Claes
2024-12-20 10:44           ` karthik nayak
2024-12-16 16:44       ` [PATCH v4 6/8] refs: introduce the `ref_transaction_update_reflog` function Karthik Nayak
2024-12-19 19:32         ` Toon Claes
2024-12-19 20:25           ` Junio C Hamano
2024-12-20 10:55             ` karthik nayak
2024-12-20 12:58             ` [PATCH] refs: mark invalid refname message for translation Karthik Nayak
2024-12-20 15:53               ` Junio C Hamano
2024-12-24 10:34                 ` Toon Claes
2024-12-16 16:44       ` [PATCH v4 7/8] refs: allow multiple reflog entries for the same refname Karthik Nayak
2024-12-19 19:33         ` Toon Claes [this message]
2024-12-20 11:15           ` karthik nayak
2024-12-16 16:44       ` [PATCH v4 8/8] refs: add support for migrating reflogs Karthik Nayak
2024-12-17  6:59       ` [PATCH v4 0/8] refs: add reflog support to `git refs migrate` Patrick Steinhardt
2024-12-17  9:35         ` karthik nayak
2024-12-17 21:28           ` Junio C Hamano
2024-12-19 19:32       ` Toon Claes
2024-12-20 11:23         ` karthik nayak

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=871py3h3ia.fsf@iotcl.com \
    --to=toon@iotcl.com \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    --cc=ps@pks.im \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).