Possible git bug - repository remote becomes hamstrung if non-existent "remote.<remote>.fetch" refspec is supplied

Summary: A git repository can become blocked from any operations relating to a specific remote if there is non-wildcard "remote.<remote>.fetch" config value set for a ref that no longer exists on that remote.

(Perhaps this is not a "bug" per se. I don't want to cause conflict by using an inflammatory term. But it is certainly something that effectively "breaks" git operation and is not debuggable or solvable by your typical end-user. I'm happy to call it something else, but I wanted to report it.)

Minimal Reproducible Example:

$> git config --local --add remote.origin.fetch "+refs/heads/foo/bar:refs/remotes/forks/foo/bar" $> git fetch fatal: couldn't find remote ref refs/heads/foo/bar fatal: the remote end hung up unexpectedly

Observe how it is not clear from the error message where the problem is at all.

"git fetch --prune" does not fix it. Once you realize what the problem is (which can take a long time), a "git config --local --unset refs/remotes/forks/foo/bar" (in the example above) is the only solution I've found. And the more generic solution below seems a bit unwieldy

for fetchref in $(git config --get-all "remote.${remote}.fetch"); do
    ref="${fetchref#:*}" # everything after the colon
    [[ "$ref" =~ \*$ ]] && continue
    if ! git ls-remote --exit-code "${remote}" "$ref" &>/dev/null; then
        echo "Bad ref: $fetchref does not exist on ${remote}. Removing."
        git config --local --unset "remote.${remote}.fetch" "$ref"
    fi
done