I removed a remote and its refs persisted. At first I thought this was a
bug but looking at add_branch_for_removal()'s "don't delete a branch if
another remote also uses it" logic it's intentional.
This goes very wrong if you do e.g.:
(
rm -rf /tmp/git &&
git clone --bare --mirror [email protected]:git/git.git /tmp/git &&
cd /tmp/git &&
git remote add avar [email protected]:avar/git.git &&
git fetch avar &&
git remote remove avar &&
git for-each-ref|grep -c refs/remotes/avar
)
At this point you can't prune it since no remote config is left:
$ git remote prune avar
fatal: 'avar' does not appear to be a git repository
fatal: Could not read from remote repository.
But this is a possible work-around:
git init /tmp/empty.git
git remote add avar file:///tmp/empty.git
git remote prune avar
git remote remove avar
Or use update-ref -d to remove them:
for rr in $(git for-each-ref --format="%(refname)"|grep ^refs/remotes/avar/)
do
git update-ref -d $rr
done
I started to patch this, but I'm not sure what to do here. we could do
some combination of:
0. Just document the current behavior and leave it.
1. Dig further down to see what other remotes reference these refs, and
just ignore any refspecs that don't explicitly reference
refs/remotes/<our_deleted_remote>/*.
I.e. isn't the intention here to preserve a case where you have two
URLs for the same effective remote, not whene you have something
like a --mirror refspec? Unfortunately I can't ask the original
author :(
2. Warn about each ref we didn't delete, or at least warn saying
there's undeleted refs under refs/remotes/<name>/*.
3. Make 'git remote remove --force-deletion <name>' (or whatever the
flag is called) be a thing. But unless we do the next item this
won't be useful.
4. Make 'git remote prune <name>' work in cases where we don't have a
remote called <name> anymore, just falling back to deleting
refs/remotes/<name>. In this case 'git remote remove
--force-deletion <name>' would also do the same thing.
In any case, the current behavior where we just leave this crap behind
without any explanation or an obvious way to delete them (can't use
git-branch -d, need update-ref -d) isn't nice.
I encountered this in the wild because GitLab will add an "upstream" ref
if you clone a repo, but if you stop using the remote to update it in
combination with their "geo" remote (which has --mirror refspecs) it'll
leave behind all these dead refs.
