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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2025-01-21 at 21:32:04, D. Ben Knoble wrote:
> On Tue, Jan 21, 2025 at 4:16 PM Emily Shaffer <nasamuffin@xxxxxxxxxx> 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

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux