Bug: git-upload-pack will return successfully even when it can't read all references

We have a process to back up our Git repositories at work, this started alerting because it wasn't getting the same refs as the remote.

This turned out to be a pretty trivial filesystem error. refs/heads/master wasn't readable by the backup process, but some other stuff in refs/heads and objects/* was.

But I think it's a bug that if we ssh to the remote end, and git-upload-pack can't read certain refs in refs/heads/ that we don't return an error.

This simple shellscript reproduces the issue:

    rm -rf /tmp/repo /tmp/repo-checkout
    git init /tmp/repo
    cd /tmp/repo
    touch foo
    git add foo
    git commit -m"foo"
    git checkout -b branch
    git checkout master
    git show-ref
    chmod 000 .git/refs/heads/master
    git show-ref
    cd /tmp
    git clone repo repo-checkout
    echo "Status code of clone: $?"
    cd repo-checkout
    git show-ref

After running this you get:

    $ (cd /tmp/repo-checkout && echo -n | strace
/tmp/avar/bin/git-upload-pack /tmp/repo 2>&1 | grep -e EACCES)
    open("refs/heads/master", O_RDONLY)     = -1 EACCES (Permission denied)
    open("refs/heads/master", O_RDONLY)     = -1 EACCES (Permission denied)
    open("refs/heads/master", O_RDONLY)     = -1 EACCES (Permission denied)

And "git fetch" will return 0.

We fail to call get refs/heads/master in head_ref_namespaced() called by upload_pack(). I was going to see if I could patch it to return an error, but that code seems very far removed from any error checking.

This isn't only an issue with git-upload-pack, e.g. show-ref itself has the same issue:

    $ chmod 600 .git/refs/heads/master
    $ git show-ref; echo $?
    e7255c8fcabc6e15f57cd984f9f117870052c1a0 refs/heads/branch
    e7255c8fcabc6e15f57cd984f9f117870052c1a0 refs/heads/master
    0
    $ chmod 000 .git/refs/heads/master
    $ git show-ref; echo $?
    e7255c8fcabc6e15f57cd984f9f117870052c1a0 refs/heads/branch
    0

I wanted to check if this was a regression and got as far back as v1.4.3 with the same behavior before the commands wouldn't work anymore due to changes in the git config parsing code.