Your message dated Thu, 12 Jan 2012 23:04:20 -0600
with message-id <20120113050419.GA21517@burratino>
and subject line Re: git: Shallow cloning fails
has caused the Debian Bug report #626212,
regarding git fetch-pack: please work around server-side shallow clone hang
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
626212: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626212
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: git
Version: 1:1.7.4.4-1
Severity: important
I have been observing that the success of shallow
cloning depends on the size of the remote repository.
The command
$ git clone --depth 2 git://git.sv.gnu.org/gnulib.git
Cloning into gnulib...
reflects correctly the extent to which the command proceeds
before waiting forever when executed with git_1:1.7.4.4-1
on my i386 system, using Wheeze/testing. Making a TCP dump
there is a NAK message, almost immediate before the message
exhange ceases. In comparison,
$ git clone git://git.sv.gnu.org/gnulib.git
[...]
Resolving deltas: 51% (48907/95596)
and the uses much time for internal computations.
Exactly the same behaviour is present on kfreebsd-amd64
with identical Git package. As long as this latter system
had 1:1.7.2.3-2 shallow cloning worked correctly.
Sometimes a cloning of depth=1 will succeed, but usually
it fails.
Contrast this to my observations that git_1:1.7.2.5-1 works
correctly for Squeeze with i386 and amd64.
A shallow clone using 1:1.7.4.4-1 of the much smaller
inetutils.git, at Savannah, fails in the same way, but
now the full depth cloning is quickly successful thanks
to the smaller size.
Somehow the recent versions of Git, or its packaging,
is not able to conduct a correct setup based on a
handshake with a shallow scope. At first I thought
32 bit would differ from 64 bit, but now I am inconclusive.
I have observed the failure in i386/testing for well over
a month, since I need to run the development bootstrap
for GNU Inetutils in order to bring in GNU lib for test
build. Personally, there is not much more I can contribute
in the way of an analysis, other than the observations that
are listed above. They do reflect my checking of four different
physical machines.
Regards,
Mats Erik Andersson, DM
--
Mats Erik Andersson, fil. dr
<[email protected]>
2459 41E9 C420 3F6D F68B 2E88 F768 4541 F25B 5D41
Abonnerar på: debian-mentors, debian-devel-games, debian-perl,
debian-ipv6, debian-qa
--- End Message ---
--- Begin Message ---
Jonathan Nieder wrote:
> So why does using an older client seem to trigger it less easily?
> Well, on this machine v1.7.2.3 has no problem triggering it; I think
> you were just lucky. I can't think of an easy way to automatically
> work around it on the client side off-hand --- better to fix the
> servers suffering from that deadlock.
The fix to 607346 is more widely deployed by now and I still have no
good ideas about when a client would want to give up on a stalled
server to try something else, so let's close this. Thanks again for
a very clear and useful report.
--- End Message ---
