> 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.
