Re: [PATCH 0/4] builtin/remote: rework how remote refs get renamed

Patrick Steinhardt [off-list ref] writes:

On the other hand this series reworks the logic used to rename remotes
so that we use two transactions instead of one transaction per ref. This
fixes quadratic runtime behaviour, where renaming 10k refs takes ~4
minutes, 100k takes hours. This results in a significant speedup with
both the "files" backend (benchmarked with a smaller number of refs to
retain sanity):

Great.  Hopefully we will teach transaction mechanism to sort out
its D/F false-positive bug so that we do not have to risk succeesing
the removal half of these two transactions while failing the adding
half of them soonish?

But in any case, it's one more case where the "reftable" backend
outperforms the "files" backend.

;-).

The series is built on top of e4ef0485fd7 (The fourteenth batch,
2025-07-24) with ps/reflog-migrate-fixes at de7cc0782a7 (refs: fix
invalid old object IDs when migrating reflogs, 2025-07-25) merged into
it.

I'd normally have withheld sending until that series was merged to
"next", but given that I promised to send something on Friday already I
decided to just get it out. In any case, if that causes problems I'm
happy to wait a bit before this series here gets merged into "seen".

Thanks!

Great.  Will queue.  If the reflog-migrate-fix needs further work,
it shouldn't be too hard to rebase this one on my end, either.