Patrick Steinhardt <ps@xxxxxx> 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@xxxxxx> > --- > builtin/fetch.c | 78 ++++++++++++++++--------------------------------- > 1 file changed, 25 insertions(+), 53 deletions(-)
