]> git.ipfire.org Git - thirdparty/git.git/commit
reftable/stack: allow locking of outdated stacks
authorPatrick Steinhardt <ps@pks.im>
Tue, 24 Sep 2024 05:33:05 +0000 (07:33 +0200)
committerJunio C Hamano <gitster@pobox.com>
Tue, 24 Sep 2024 16:45:25 +0000 (09:45 -0700)
commit80e7342ea8ecda48bdf034e77c32ac1c5d2bda85
treecb13642079427147d3d58ecb323467cf3a9ed22b
parentbc39b6a796eb707c34ffb759d50a75f96313f26c
reftable/stack: allow locking of outdated stacks

In `reftable_stack_new_addition()` we first lock the stack and then
check whether it is still up-to-date. If it is not we return an error to
the caller indicating that the stack is outdated.

This is overly restrictive in our ref transaction interface though: we
lock the stack right before we start to verify the transaction, so we do
not really care whether it is outdated or not. What we really want is
that the stack is up-to-date after it has been locked so that we can
verify queued updates against its current state while we know that it is
locked for concurrent modification.

Introduce a new flag `REFTABLE_STACK_NEW_ADDITION_RELOAD` that alters
the behaviour of `reftable_stack_init_addition()` in this case: when we
notice that it is out-of-date we reload it instead of returning an error
to the caller.

This logic will be wired up in the reftable backend in the next commit.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
refs/reftable-backend.c
reftable/reftable-stack.h
reftable/stack.c
t/unit-tests/t-reftable-stack.c