Re: Pathological performance with git remote rename and many tracking refs

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

On 2022-04-14 at 07:12:20, Ævar Arnfjörð Bjarmason wrote:
> Aside from how we'd do renames with transactions, do you know about
> clone.defaultRemoteName and --origin?

Yes, I do know about that.  However, in my case, the repository is
cloned before I even get a chance to touch it, so these options have no
effect.  My dotfiles aren't even on the machine at that point.

> There was a (small) thread as a follow-up to that "rename --progress"
> patch at the time, did you spot/read that?:
> https://lore.kernel.org/git/220302.865yow6u8a.gmgdl@evledraar.gmail.com/

Yeah, I remember reading it at the time.

> More generally, probably:
> 
>  1. Teach transactions about N operations on the same refname, which
>     they'll currently die on, renames are one case.
> 
>  2. Be able to "hook in" to them, updating reflogs is one special-case,
>     but we have the same inherent issue with updating config in lockstep
>     with transactions.

Yeah, that's one of the reasons I was thinking of implementing
--no-reflogs: because in that case, the operation really is a
create/delete operation and it doesn't require any additional logic in
the transaction.

My goal here is specifically not to rearchitect ref transactions and to
implement a relatively simple solution.  Your response is indicating to
me that updating reflogs is going to be the former and not the latter.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]