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

[Junio C Hamano <gitster@pobox.com>]

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(-)