All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Bryan Turner <bturner@atlassian.com>,
	Waleed Khan <me@waleedkhan.name>
Subject: Re: [PATCH v2 6/6] refs: skip hooks when deleting uncovered packed refs
Date: Mon, 10 Jan 2022 14:18:14 +0100	[thread overview]
Message-ID: <YdwyFmqs0MhU0wA6@ncase> (raw)
In-Reply-To: <xmqq1r1j3s0v.fsf@gitster.g>

[-- Attachment #1: Type: text/plain, Size: 5588 bytes --]

On Fri, Jan 07, 2022 at 06:01:04PM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > When deleting refs from the loose-files refs backend, then we need to be
> > careful to also delete the same ref from the packed refs backend, if it
> > exists. If we don't, then deleting the loose ref would "uncover" the
> > packed ref. We thus always have to queue up deletions of refs for both
> > the loose and the packed refs backend. This is done in two separate
> > transactions, where the end result is that the reference-transaction
> > hook is executed twice for the deleted refs.
> >
> > This behaviour is quite misleading: it's exposing implementation details
> > of how the files backend works to the user, in contrast to the logical
> > updates that we'd really want to expose via the hook. Worse yet, whether
> > the hook gets executed once or twice depends on how well-packed the
> > repository is: if the ref only exists as a loose ref, then we execute it
> > once, otherwise if it is also packed then we execute it twice.
> 
> If the ref only exists as a packed ref, what happens? ...
> 
> > Fix this behaviour and don't execute the reference-transaction hook at
> > all when refs in the packed-refs backend if it's driven by the files
> > backend.
> 
> ... We try to remove from the loose backend, which would say "nah,
> it did not exist in my store".  I am not sure if it should execute
> the delete hook in such a case for the ref.  But if it does not, not
> running the hook in the ref transaction for packed backend driven by
> the loose backend would mean nobody notifies the deletion of the
> ref, no?

This is shown in the test I've added, "deleting packed ref calls hook
once". We create a new reference and pack it such that it doesn't exist
as loose ref anymore, but only as a packed one. Updating that ref
would've caused us to execute the hook twice before, once via the
packed-backend and once via the loose-backend. With my fix we only
execute it once via the loose-backend, even if it doesn't currently know
it. This works because the loose-backend has to create a lock for the
nonexistent reference such that no concurrent call touches the same ref.

> To me, it seems that the only case this strategy would work
> correctly is when the files backend calls deletion hook for a
> request to delete nonexistent ref, which by itself sounds like a
> problem.

It does so only if the ref exists in either the loose or packed backend
though. If trying to update a ref which exists in neither of those, then
the reference transaction would fail with an "unable to resolve
reference" error in `lock_raw_ref()`.

So this should behave as expected: deleting a packed ref calls the hook
once, deleting a nonexistent ref fails and doesn't call the hook at all.

Patrick

> > Signed-off-by: Patrick Steinhardt <ps@pks.im>
> > ---
> >  refs/files-backend.c             | 9 ++++++---
> >  t/t1416-ref-transaction-hooks.sh | 7 +------
> >  2 files changed, 7 insertions(+), 9 deletions(-)
> >
> > diff --git a/refs/files-backend.c b/refs/files-backend.c
> > index 3c0f3027fe..9a20cb8fa8 100644
> > --- a/refs/files-backend.c
> > +++ b/refs/files-backend.c
> > @@ -1261,7 +1261,8 @@ static int files_delete_refs(struct ref_store *ref_store, const char *msg,
> >  	if (packed_refs_lock(refs->packed_ref_store, 0, &err))
> >  		goto error;
> >  
> > -	transaction = ref_store_transaction_begin(refs->packed_ref_store, 0, &err);
> > +	transaction = ref_store_transaction_begin(refs->packed_ref_store,
> > +						  REF_TRANSACTION_SKIP_HOOK, &err);
> >  	if (!transaction)
> >  		goto error;
> >  
> > @@ -2775,7 +2776,8 @@ static int files_transaction_prepare(struct ref_store *ref_store,
> >  			 */
> >  			if (!packed_transaction) {
> >  				packed_transaction = ref_store_transaction_begin(
> > -						refs->packed_ref_store, 0, err);
> > +						refs->packed_ref_store,
> > +						REF_TRANSACTION_SKIP_HOOK, err);
> >  				if (!packed_transaction) {
> >  					ret = TRANSACTION_GENERIC_ERROR;
> >  					goto cleanup;
> > @@ -3046,7 +3048,8 @@ static int files_initial_transaction_commit(struct ref_store *ref_store,
> >  				 &affected_refnames))
> >  		BUG("initial ref transaction called with existing refs");
> >  
> > -	packed_transaction = ref_store_transaction_begin(refs->packed_ref_store, 0, err);
> > +	packed_transaction = ref_store_transaction_begin(refs->packed_ref_store,
> > +							 REF_TRANSACTION_SKIP_HOOK, err);
> >  	if (!packed_transaction) {
> >  		ret = TRANSACTION_GENERIC_ERROR;
> >  		goto cleanup;
> > diff --git a/t/t1416-ref-transaction-hooks.sh b/t/t1416-ref-transaction-hooks.sh
> > index f9d3d5213f..4e1e84a91f 100755
> > --- a/t/t1416-ref-transaction-hooks.sh
> > +++ b/t/t1416-ref-transaction-hooks.sh
> > @@ -175,16 +175,11 @@ test_expect_success 'deleting packed ref calls hook once' '
> >  	git update-ref -d refs/heads/to-be-deleted $POST_OID &&
> >  
> >  	# We only expect a single hook invocation, which is the logical
> > -	# deletion. But currently, we see two interleaving transactions, once
> > -	# for deleting the loose refs and once for deleting the packed ref.
> > +	# deletion.
> >  	cat >expect <<-EOF &&
> > -		prepared
> > -		$ZERO_OID $ZERO_OID refs/heads/to-be-deleted
> >  		prepared
> >  		$POST_OID $ZERO_OID refs/heads/to-be-deleted
> >  		committed
> > -		$ZERO_OID $ZERO_OID refs/heads/to-be-deleted
> > -		committed
> >  		$POST_OID $ZERO_OID refs/heads/to-be-deleted
> >  	EOF

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-01-10 13:18 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-07 10:55 [PATCH 0/6] refs: excessive hook execution with packed refs Patrick Steinhardt
2021-12-07 10:55 ` [PATCH 1/6] refs: open-code deletion of " Patrick Steinhardt
2021-12-07 10:56 ` [PATCH 2/6] refs: allow passing flags when beginning transactions Patrick Steinhardt
2021-12-07 10:56 ` [PATCH 3/6] refs: allow skipping the reference-transaction hook Patrick Steinhardt
2021-12-07 10:56 ` [PATCH 4/6] refs: demonstrate excessive execution of " Patrick Steinhardt
2021-12-07 10:56 ` [PATCH 5/6] refs: do not execute reference-transaction hook on packing refs Patrick Steinhardt
2021-12-07 10:56 ` [PATCH 6/6] refs: skip hooks when deleting uncovered packed refs Patrick Steinhardt
2022-01-07 11:55 ` [PATCH v2 0/6] refs: excessive hook execution with " Patrick Steinhardt
2022-01-07 11:55   ` [PATCH v2 1/6] refs: open-code deletion of " Patrick Steinhardt
2022-01-08  0:57     ` Junio C Hamano
2022-01-08  1:51     ` Junio C Hamano
2022-01-13  0:24     ` Junio C Hamano
2022-01-07 11:55   ` [PATCH v2 2/6] refs: allow passing flags when beginning transactions Patrick Steinhardt
2022-01-08  1:51     ` Junio C Hamano
2022-01-07 11:55   ` [PATCH v2 3/6] refs: allow skipping the reference-transaction hook Patrick Steinhardt
2022-01-07 11:55   ` [PATCH v2 4/6] refs: demonstrate excessive execution of " Patrick Steinhardt
2022-01-08  1:31     ` Junio C Hamano
2022-01-10 12:54       ` Patrick Steinhardt
2022-01-08  5:43     ` Eric Sunshine
2022-01-07 11:55   ` [PATCH v2 5/6] refs: do not execute reference-transaction hook on packing refs Patrick Steinhardt
2022-01-07 11:55   ` [PATCH v2 6/6] refs: skip hooks when deleting uncovered packed refs Patrick Steinhardt
2022-01-08  2:01     ` Junio C Hamano
2022-01-10 13:18       ` Patrick Steinhardt [this message]
2022-01-10 18:00         ` Junio C Hamano
2022-01-07 22:17   ` [PATCH v2 0/6] refs: excessive hook execution with " Junio C Hamano
2022-01-13 18:24     ` Han-Wen Nienhuys
2022-01-17  7:18       ` Patrick Steinhardt
2022-01-17 11:37         ` Han-Wen Nienhuys
2022-01-24  7:13           ` Patrick Steinhardt
2022-01-13  6:11   ` [PATCH v3 " Patrick Steinhardt
2022-01-13  6:11     ` [PATCH v3 1/6] refs: extract packed_refs_delete_refs() to allow control of transaction Patrick Steinhardt
2022-01-13 12:43       ` Ævar Arnfjörð Bjarmason
2022-01-17  7:36         ` Patrick Steinhardt
2022-01-13  6:11     ` [PATCH v3 2/6] refs: allow passing flags when beginning transactions Patrick Steinhardt
2022-01-13  6:11     ` [PATCH v3 3/6] refs: allow skipping the reference-transaction hook Patrick Steinhardt
2022-01-13 13:34       ` Ævar Arnfjörð Bjarmason
2022-01-17  8:03         ` Patrick Steinhardt
2022-01-13  6:11     ` [PATCH v3 4/6] refs: demonstrate excessive execution of " Patrick Steinhardt
2022-01-13  6:11     ` [PATCH v3 5/6] refs: do not execute reference-transaction hook on packing refs Patrick Steinhardt
2022-01-13 13:00       ` Ævar Arnfjörð Bjarmason
2022-01-17  7:44         ` Patrick Steinhardt
2022-01-13  6:11     ` [PATCH v3 6/6] refs: skip hooks when deleting uncovered packed refs Patrick Steinhardt
2022-01-13 13:04       ` Ævar Arnfjörð Bjarmason
2022-01-17  7:56         ` Patrick Steinhardt
2022-01-17  8:12   ` [PATCH v4 0/6] refs: excessive hook execution with " Patrick Steinhardt
2022-01-17  8:12     ` [PATCH v4 1/6] refs: extract packed_refs_delete_refs() to allow control of transaction Patrick Steinhardt
2022-01-17  8:12     ` [PATCH v4 2/6] refs: allow passing flags when beginning transactions Patrick Steinhardt
2022-01-17  8:12     ` [PATCH v4 3/6] refs: allow skipping the reference-transaction hook Patrick Steinhardt
2022-01-17  8:12     ` [PATCH v4 4/6] refs: demonstrate excessive execution of " Patrick Steinhardt
2022-01-17  8:12     ` [PATCH v4 5/6] refs: do not execute reference-transaction hook on packing refs Patrick Steinhardt
2022-01-17  8:12     ` [PATCH v4 6/6] refs: skip hooks when deleting uncovered packed refs Patrick Steinhardt

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=YdwyFmqs0MhU0wA6@ncase \
    --to=ps@pks.im \
    --cc=bturner@atlassian.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@waleedkhan.name \
    --cc=peff@peff.net \
    /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.