Re: Partial clone fails with file:/// URI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 14, 2020 at 06:04:18PM +0100, Nipunn Koorapati wrote:

> I've been building git from source and directly using the executable. Roughly
> ```
> cd git
> make
> cd ..
> git/git clone --filter=blob:none file://$(pwd)/git a_clone_of_git
> ```

Note that running a built copy directly without installing may end up
running a different version of Git under the hood. Your initial
"git/git" will run the newly built version, but it will put the
to-be-installed exec-path at the front of $PATH (probably
~/libexec/git-core if you haven't configured anything). But since you
haven't installed anything there, that won't do anything, and instead
any git subprocesses it runs (including the server-side upload-pack and
any child fetches it runs to get the blobs) will be done with whatever
version of git is in your $PATH already.

Try:

  git/bin-wrappers/git clone ...

which is a shell script that sets up the exec-path properly for running
out of the build directory.

When I run your commands, I get:

  error: Server does not allow request for unadvertised object d16e5f041f5d3ad91129c4fe6713c71727895e9c
  error: unable to read sha1 file of Documentation/RelNotes/2.1.4.txt (d16e5f041f5d3ad91129c4fe6713c71727895e9c)

and so on for each object. Some older versions of Git did not correctly
handle this situation (they asked for the object even though the server
did not claim to allow it). It was fixed in 2b69d3116f (Merge branch
'mm/fetch-show-error-message-on-unadvertised-object' into maint,
2017-03-28), I think, in v2.21.3. If your system Git is older than that,
this might be the culprit.

> This is what I was missing:
> git config uploadpack.allowanysha1inwant true

Note that you shouldn't need to do that starting with v2.29, because the
v2 protocol is the default (which always allows any sha1 to be
requested).

> If this is not set, then the checkout fails w/ a
> 
> fatal: protocol error: bad pack header
> 
> Perhaps the error message and/or docs could be improved here to
> something with more detail than "bad pack header"?

The problem is that the client is hanging up when we are trying to read
the pack header. I think in newer versions of Git this is better, as
well (the server is better about sending an over-the-wire ERR packet,
and the client is better about reading and relaying it, though there are
still some races around write() errors here).

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux