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

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

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