I’m implementing an option in my application to use --depth 1 to make a minimal functional clone of a git repo, and I’ve just realized that the dumb http transport doesn’t support --depth. I’d like to automatically detect whether an http remote is dumb or smart so I can omit the --depth option when talking to dumb http repos. Is this possible?

Alternately, is there a direct way to check whether a git remote supports --depth?

2 Solutions collect form web for “Is it possible to detect whether a http git remote is smart or dumb?”

One way is by direct HTTP queries.

Smart-supporting git clients add an argument to the end of the first URL grabbed, “[repo]/info/refs?service=git-upload-pack”. A dumb server will just send “info/refs” file as text ignoring the argument, while a smart server will return some binary data in front of the refs list, including text “service=git-upload-pack” and a list of features (which you might be able to figure out “depth” support from).

You can script this smart/dumb test by using wget or curl to check the MIME type: text/plain (dumb) vs. application/x-git-upload-pack-advertisement (smart).

(Pipe to grep -q "^Content-Type: application/x-git" and use the return code for true/false test.)

I believe since git 1.8.2, you can check the Content-Type header.
That is why commit git/git/4656bf47 mentions:

Before parsing a suspected smart-HTTP response verify the returned Content-Type matches the standard. This protects a client from attempting to process a payload that smells like a smart-HTTP server response.

You can see an example of setting that field in commit sitaramc/gitolite/32d14d39: