Patrick Steinhardt <ps@xxxxxx> 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.