Re: [Feature Request] Allow batch removal of remotes with 'git remote remove'

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jan 22, 2025, 02:24 UTC
Message-ID: <Z5BW5ofJVbM1obb5@tapette.crustytoothpaste.net>
In-Reply-To: <CALnO6CAEaOUNwMpOTF8wKVd7LAv+UiU5W62ZCBc0U-K_JhHU-g@mail.gmail.com>

On 2025-01-21 at 21:32:04, D. Ben Knoble wrote:

Show 13 quoted lines

> On Tue, Jan 21, 2025 at 4:16 PM Emily Shaffer <nasamuffin@google.com> wrote:
> >
> > Hi Christian, is there a reason why opening up the config (`vim
> > .git/config` or `git config edit --local`) and batch-deleting remotes
> > from there is undesirable? If this is a solution you believe only
> > power users need, then I'd posit a power user can both list all
> > remotes *and* remove the offending ones in a single editor pass,
> > rather than having to run multiple `git remote` commands, anyway.
> 
> I'd posit a power user can also do something a bit like (Zsh with GNU
> or FreeBSD xargs) `print -N my remotes to delete | xargs -0n1 git
> remote remove`, or (portably) `for remote in my remotes to delete; do
> git remote remove "$remote"; done`.

I agree that is possible, but it may not perform well. I used to work at a company where, for many years, I merged other developers' code by hand and pushed it, which necessitated having everyone's remote. In the main project, there were many people's feature and development branches in their remotes, so I had well over 80,000 refs in my repository.

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.

So I think this feature would be useful, although I agree that for many smaller repos, the shell script approach would be acceptable in the interim.

[0] Sometime back I reported that `git remote rename` on a fresh clone with 45,000 refs took about 45 minutes. The reason I didn't choose the remote name on the original clone (with `-o`) is because it was in a GitHub Codespace, which had cloned it for me already. Fortunately, this is now down to about 55 to 78 seconds with reftable, which is a major improvement, and I'm sure we could do better still.

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA