Re: [PATCH v4] builtin/clone.c: add --reject-shallow option

[Jonathan Tan <jonathantanmy@google.com>]

> This may reject to clone from a shallow repository, but at this
> point the bulk of the tranfer from the origin repository has already
> happened, no?  Rejecting after transferring many megabytes feels a
> bit too late.  That is one of the reasons why I kept hinting that
> the transport layer needs to be taught an option to reject talking
> to a shallow counterpart if we want to add this feature [*1*].

Extending the transport layer in this way might not be too difficult in
the case of native (SSH, git://) protocols and using protocol v0, since
handshake() in transport.c (called indirectly from
transport_get_remote_refs()) writes shallow information to a data
structure that we could potentially expose for the caller to use (before
it calls transport_fetch_refs(). I couldn't see how remote-using
protocols (e.g. HTTP) communicate shallow information, though
(remote-curl.c seems to just keep it for itself), so that will be a more
difficult task. And of course there's the matter of protocol v2, which I
discuss below.

> [Footnote]
> 
> *1* Looking at Documentation/technical/pack-protocol.txt, "git
>     fetch" seem to learn if the repository is shallow immediately
>     upon contacting "upload-pack" during the Reference Discovery
>     phase (we'd see 'shallow' packets if they are shallow). I
>     suspect that the right solution would be to teach the codepath
>     on the "git fetch" side that accepts, parses, and acts on this
>     packet to optionally stop communication and error out when the
>     caller asks not to talk with a shallow repository.

This is true with protocol v0, but protocol v2 bundles all shallow
information (whether coming from the fact that the remote is shallow or
the fact that the fetcher specified --depth etc.) and sends them
together with the packfile. It may be possible to stop packfile download
(saving bandwidth on the client side, at least) once such information is
returned, though.