Avoid race condition between fetch and repack/gc?

Hi all,

we occasionally seeing things like this:

| DEBUG: 11:25:20: git -c advice.fetchShowForcedUpdates=false fetch --no-show-forced-updates -q --prune
| Warning: Permanently added '[socgit.$company.com]:7999' (RSA) to the list of known hosts.
| remote: fatal: packfile ./objects/pack/pack-20256f2be3bd51b57e519a9f2a4d3df09f231952.pack cannot be accessed        
| error: git upload-pack: git-pack-objects died with error.
| fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
| remote: aborting due to possible repository corruption on the remote side.
| fatal: protocol error: bad pack header

and when you look in the server repository there is a new packfile dated just around
that time. It looks like the fetch tries to access a packfile that it assumes to exist,
but the GC on the server throws it away just in that moment, and thus upload-pack fails.

Is there a way to avoid this?

Should there be, like git repack waiting a bit before deleting old packfiles?

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800