Re: maybe breakage with latest git-pull and http protocol

From: Junio C Hamano <junkio@cox.net>
Date: Oct 15, 2005, 16:04 UTC
Message-ID: <7vd5m6py11.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <863bn3lypn.fsf@blue.stonehenge.com>

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> OK, it happened this morning.  While syncing to update from
> yesterday's version, I got:

Thanks.

Show 11 quoted lines

>     localhost:~/MIRROR/git-GIT % git-pull
>     Fetching refs/heads/master from http://www.kernel.org/pub/scm/git/git.git using http
>     Getting alternates list
>     got 4546738b58a0134eef154231b07d60fc174d56e3
>     walk 4546738b58a0134eef154231b07d60fc174d56e3
>     got d402d5566fdf226697a386dfb9858e5d954e9b91
>     got 873d8e5652c06c3891278f33546c437efc209c2d
>     walk d402d5566fdf226697a386dfb9858e5d954e9b91
>     error: 
>     Getting pack list
>     got 0207ab18a3876249a928e7539d8f594a4f6921f1

Here is the beginning of a session that succeeded:

    : siamese; GIT_DIR=. git-http-fetch -v -a heads/master \
               http://www.kernel.org/pub/scm/git/git.git/
    Getting alternates list
    got 4546738b58a0134eef154231b07d60fc174d56e3
    walk 4546738b58a0134eef154231b07d60fc174d56e3
    got d402d5566fdf226697a386dfb9858e5d954e9b91
    got 873d8e5652c06c3891278f33546c437efc209c2d
    got 5ad4a2766d34569f3a1278544ab64978fab14cc8
    walk d402d5566fdf226697a386dfb9858e5d954e9b91
    ...

The difference is that this log gets 5ad4a2 blob, before it starts walking d402d5 commit, while Merlyn's log shows we tried to walk that commit before getting the blob. I think what is happening is:

    - we request 454673 commit, and get it.

    - we start requesting trees, blobs, and parent commit
      reachable from it.  Especially, 5ad4a2 blob and d402d5
      commit are asked.

    - as soon as d402d5 commit arrives we walk and find out we
      need 5ad4a2 blob.  In the case that happened to work, that
      blob has already arrived because it was also part of the
      454673 commit, but in Merlyn's case that blob has not
      arrived yet. "Getting pack list" on the next line is an
      indication that the fetch_object incorrectly decided that
      the object we are waiting for is not available unpacked,
      which does not (and should not) happen in the case we got
      the blob object in time.

I have a suspicion that the recent multi-fetch work has some interesting interaction with the assumption Sergey's fetch.c optimization makes.