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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 28, 2025, 15:43 UTC
Message-ID: <xmqqzfcowcat.fsf@gitster.g>
In-Reply-To: <20250728-pks-remote-rename-improvements-v1-0-f654f2b5c5ae@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 6 quoted lines

> 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.

;-).

Show 11 quoted lines

> 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.