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

> > It's hard to bring myself to care, though. This is a stupidly
> > pathological reflog, and the absolute time change is peanuts compared to
> > the per-ref cost you're fixing here.
> 
> For the "files" backend performance is worse, for the "reftable" backend
> I'd expect that this might even be faster. Mostly because there is no
> way to trivially rename a reflog -- we basically do the same on a rename
> as we are doing with this patch series now.
> 
> Overall I don't care too much about this edge case. By default we never
> write reflogs for remote references anyway, and I doubt that you'll ever
> end up with a remote reflog that has thousands of entries. So I'd rather
> make the general case fast even if the esoteric case becomes slower.
> 
> But ideally we're able to lift such limitations in the future if we were
> to do the above rework.