Jeff King <peff@xxxxxxxx> writes: > On Wed, Jan 22, 2025 at 02:24:38AM +0000, brian m. carlson wrote: > >> Because `git remote remove` will remove remote-tracking branches and >> their reflogs, we typically will want to do that all at once in a single >> ref transaction, and hence in one command. Not doing so performs very >> poorly (as does, notably `git remote rename`[0]) when all of the refs are >> packed. If you have a large number of remotes to delete and a large >> number of total refs, this will perform really badly indeed, since the >> operation of rewriting the packed-refs file becomes quadratic. >> >> The removal of the remote-tracking branches is also the reason that >> editing the config isn't sufficient, either. > > I think the config update is probably quadratic, too (in the number of > remotes). Each one is going to rewrite the whole config file, minus its > matching section. But a "remove" operation that took multiple remotes > could do it all in a single pass. > > If somebody does implement "remote remove" that takes multiple names, I > hope they'll refactor to do all of the operations in a single pass, and > not just loop on builtin/remote.c:rm() internally. > > Probably git-config could stand to learn similar tricks, too. There is > "--remove-section", but I don't think you can pass multiple sections > (and it's likewise quadratic). Thanks for bringing up the performance aspect and where the problem lies in the current implementation.
