Re: git fetch sha1

From: Shawn Pearce <spearce@spearce.org>
Date: Jul 5, 2014, 16:30 UTC
Message-ID: <CAJo=hJubkP-D0qnHQYdRC+bjt_2oTNNzgbgPqVG-DursARLrAw@mail.gmail.com>
In-Reply-To: <CABo2x6CJz6PSFCDfn47cVQi44-J0oHsGqzSiyBe8Kt5NgWibog@mail.gmail.com>

On Sat, Jul 5, 2014 at 6:05 AM, Allan Gardner <allanegardner@gmail.com> wrote:

Show 56 quoted lines

> On Fri, Jul 4, 2014 at 10:41 PM, Shawn Pearce <spearce@spearce.org> wrote:
>>
>> On Fri, Jul 4, 2014 at 10:51 AM, Allan Gardner <allanegardner@gmail.com> wrote:
>> > Currently fetching a sha1 fails on git.kernel.org:
>> >
>> > $ git --version && uname -a
>> > git version 1.9.4
>> > Linux nixos 3.12.23 #1-NixOS SMP Thu Jan 1 00:00:01 UTC 1970 x86_64 GNU/Linux
>> >
>> > $ rm -rf test && mkdir test && cd test && git init
>> > Initialized empty Git repository in ~/test/.git/
>> >
>> > $ git fetch --depth 1 https://git.kernel.org/pub/scm/git/git.git
>> > 782735203c316041df120748e5e88c1787cdf4da
>> > error: no such remote ref 782735203c316041df120748e5e88c1787cdf4da
>> >
>> > I tried with head, same error. However, if I clone the full repository
>> > and then manually execute git upload-pack, it successfully fetches the
>> > commit:
>> >
>> > $ git fetch https://git.kernel.org/pub/scm/git/git.git master
>> > <wait an hour>
>> > $ git checkout -b sha1 782735203c316041df120748e5e88c1787cdf4da
>> > $ printf "0045want %s multi_ack_detailed\n000Ddeepen
>> > 1\n00000009done\n0000" "782735203c316041df120748e5e88c1787cdf4da"
>> >>input
>> > $ cat input | git upload-pack --stateless-rpc . > output
>> > $ sed -z "s/.*0008NAK\n//" < output > output.pack
>> > $ git index-pack output.pack && git verify-pack -v output.pack | grep commit
>> > f239687a5dbbd1bbb761d09edec582418c66c297
>> > 782735203c316041df120748e5e88c1787cdf4da commit 374 234 12
>> >
>> > So theoretically this is supported server-side. Unfortunately
>> > kernel.org does not agree:
>>
>> No, it is not supported server side. Your test didn't even test what
>> you think it tested.
>>
>> $ curl https://git.kernel.org/pub/scm/git/git.git/info/refs?service=git-upload-pack
>> 2>/dev/null | head -n 2
>> 001e# service=git-upload-pack
>> 0000009b6f92e5ff3cdc813de8ef5327fd4bad492fb7d6c9 HEADmulti_ack
>> thin-pack side-band side-band-64k ofs-delta shallow no-progress
>> include-tag multi_ack_detailed
>>
>> The capability you are asking about is allow-tip-sha1-in-want which
>> does not appear in the server advertisement. So its not supported on
>> this server.
>
> $ git upload-pack --advertise-refs --stateless-rpc .
> 00d16f92e5ff3cdc813de8ef5327fd4bad492fb7d6c9 HEADmulti_ack thin-pack
> side-band side-band-64k ofs-delta shallow no-progress include-tag
> multi_ack_detailed no-done symref=HEAD:refs/heads/master
> agent=git/1.9.4
>
> I did not ask about allow-tip-sha1-in-want,

I think you did. You asked about passing a random SHA-1 to `git fetch`. The client will only send this SHA-1 to the server if an advertised ref exactly matches or the server advertised allow-tip-sha1-in-want. Otherwise, it errors out.

> and it is not enabled by
> default. It appears that the server must advertise no-done though,
> which indeed git.kernel.org does not.

no-done is unrelated to passing a SHA-1 on the fetch line. The two concepts have nothing to do with each other. I seriously doubt anyone piggybacked additional features onto no-done years after it was introduced.

> So my next question is how
> git.kernel.org can set up the smart HTTP protocol without using
> --stateless-rpc; I guess I will have to ask them.

Haha!

Good luck with that. Current implementation requires --stateless-rpc to run smart HTTP.