"git clone --depth=2 git://git.sv.gnu.org/gnulib" hangs

Hello,

We've had a report that this command is hanging:

    git clone --depth=2 git://git.sv.gnu.org/gnulib

cloning without --depth=N works, as well as when using an ssh:// URL, but most people can use ssh:// URLs.

Normally it wouldn't be much of a problem, but many projects use gnulib as a submodule, and one of the recommended (scripted) ways to get a copy is via a shallow clone.

savannah's server is running git-1.7.2.5. I've confirmed it using these client versions:

    1.7.5.rc3.316.gd1ff9
    1.7.4.4

GIT_TRACE didn't give much info:

    xx$ GIT_TRACE=1 git clone --depth 2 git://git.sv.gnu.org/gnulib
    trace: built-in: git 'clone' '--depth' '2' 'git://git.sv.gnu.org/gnulib'
    Cloning into gnulib...
    trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' \
      '--keep=fetch-pack 645 on xx.meyering.net'
    trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' \
      '--keep=fetch-pack 645 on xx.meyering.net'
    trace: built-in: git 'index-pack' '--stdin' '-v' '--fix-thin' \
      '--keep=fetch-pack 645 on xx.meyering.net'

It appears to be something specific to the gnulib repository, since I can do a shallow clone of e.g., this one just fine:

    git://git.savannah.gnu.org/parallel.git

Any hints?

At worst I'll set up a git server on a private system and debug it -- eventually.

Regards,

Jim

Jim Meyering <jim@meyering.net> writes:

When cloing without --depth I see the resolving deltas phase busy for a minute at 50%. Perhaps related?

Andreas.

On Mon, Apr 25, 2011 at 10:28:10PM +0200, Jim Meyering wrote:

It might be related to this deadlock which impacts upload-pack on a server with pthreads serving a shallow clone:

  http://thread.gmane.org/gmane.comp.version-control.git/170789

Unfortunately the fix I posted is not yet in any released version of git. It is in the current 'next'.

It's a race condition on filling up a rev-list buffer, so certain repos may be more prone to triggering the race than others.

-Peff

Jeff King wrote:

Thanks for the pointer.  That looks very promising.

Hoping to be able to test your fix, I rsync'd the offending repository to a system on which I can experiment safely, but so far have been unable to reproduce the failure there. Of course, if my problem is indeed due to the race condition bug that your patch fixes, it's not surprising that it is unreproducible in a different environment.