Am 20.04.2018 um 14:14 schrieb Ævar Arnfjörð Bjarmason: > 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 This won't do it also? git remote prune origin > 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. Possible 5): Don't fix "git remote remove" but "git remote add" to complain that its ref-namespace is already occupied by some other remote. Add "--force" for the experts.
