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
