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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Apr 15, 2022, 01:08 UTC
Message-ID: <YljFnJk55WYLKd6Y@camp.crustytoothpaste.net>
In-Reply-To: <220414.8635igdtfn.gmgdl@evledraar.gmail.com>

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.

Show 8 quoted lines

> 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