Comment 3 for bug 1229352

And centos6-5 was just reported exhibiting this as well. I've confirmed that the behavior is basically the same as what I saw on centos6-8 last week...

    -bash-4.1$ cp -ax workspace/gate-nova-python26.broken testing
    -bash-4.1$ cd testing/
    -bash-4.1$ git remote -v
    origin git://git.openstack.org/openstack/nova (fetch)
    origin git://git.openstack.org/openstack/nova (push)
    -bash-4.1$ git remote update
    Fetching origin
    error: fetch died of signal 13
    error: Could not fetch origin
    -bash-4.1$ git fsck
    dangling commit 7015605b3e639350a1a7203b332256e6394014f1
    dangling commit 0c47cac76a88edf97d995f01d8f2c52e1c4d8f56
    dangling commit e2a225491ccabb5722c57829f65d1951db7cf937
    -bash-4.1$ git gc
    Counting objects: 215925, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (81823/81823), done.
    Writing objects: 100% (215925/215925), done.
    Total 215925 (delta 156513), reused 183643 (delta 127638)
    -bash-4.1$ git fsck
    -bash-4.1$ git remote update
    Fetching origin
    remote: Counting objects: 656, done.
    remote: Compressing objects: 100% (409/409), done.
    remote: Total 474 (delta 327), reused 135 (delta 52)
    Receiving objects: 100% (474/474), 91.95 KiB, done.
    Resolving deltas: 100% (327/327), completed with 66 local objects.
    From git://git.openstack.org/openstack/nova
       3db4372..852d7c7 master -> origin/master

The fact that we're only seeing this so far with the nova tests on CentOS 6.4 unit test slaves suggests there's something about the version of git client being used there which is exposed/exacerbated by the size of nova's Git repository or the length of time it takes to perform a remote update for it.

As a stop-gap, we might want to make the gerrit-git-prep builder perform a prophylactic 'git gc' before beginning to remote update.