Re: [RFC] fetch: update refs in a single transaction

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 9, 2021, 21:53 UTC
Message-ID: <xmqqzgp9o379.fsf@gitster.g>
In-Reply-To: <259de62b26302c10f429d52bec42a8a954bc5ba3.1638886972.git.ps@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

> instead of creating one slice per updated ref. While this inefficiency
> can be easily mitigated by using the `--atomic` flag, this flag cannot
> be used in contexts where we want partial-update semantics.

Interesting and puzzling. In today's code, we use a single transaction when "atomic" is asked for, so that we can open a transaction, prepare bunch of ref updates, and say "commit" to commit all of them and let the ref_transaction layer to make the whole thing all-or-none. If we now use a single transaction for two refs update that do not have to be atomic, it is surprising (from the diffstat) that we can do so without changing anything in the ref_transaction layer. Doesn't the caller at least need to say "this transaction is best-effort 'partial-update' (whatever it means)" vs "this transaction is all-or-none"? And doesn't the ref_transaction layer now need to implement the 'partial-update' thing?

> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  builtin/fetch.c | 78 ++++++++++++++++---------------------------------
>  1 file changed, 25 insertions(+), 53 deletions(-)