2012-02-14 16 views
6

Estoy implementando una opción en mi aplicación para usar --depth 1 para hacer un clon funcional mínimo de un repositorio git, y me acabo de dar cuenta de que el transporte HTTP tonto no es compatible con --depth. Me gustaría detectar automáticamente si un control remoto http es tonto o inteligente, así que puedo omitir la opción --depth cuando hablo con tontos repositorios http. es posible?¿Es posible detectar si un control remoto http git es inteligente o tonto?

O bien, ¿hay una forma directa de comprobar si un control remoto git admite --depth?

+0

Usaría mecanografía de pato: supongamos que es un pato y tíralo al estanque, si fuera un gato, pídele disculpas (y quizás evites volver a tirarlo al estanque). – redShadow

Respuesta

5

Una forma es mediante consultas HTTP directas.

Los clientes de git compatibles con Smart agregan un argumento al final de la primera URL tomada, "[repo]/info/refs? Service = git-upload-pack". Un servidor tonto simplemente enviará el archivo "info/refs" como texto ignorando el argumento, mientras que un servidor inteligente devolverá algunos datos binarios delante de la lista de referencias, incluido el texto "service = git-upload-pack" y una lista de características (de lo cual podrías deducir soporte de "profundidad").

Puede crear una secuencia de comandos de esta prueba inteligente/tonta usando wget o curl para verificar el tipo MIME: text/plain (tonto) vs. application/x-git-upload-pack-advertisement (smart).

$ curl -si http://github.com/git/git.git/info/refs?service=git-upload-pack | grep --binary-files=text '^Content-Type' 
Content-Type: application/x-git-upload-pack-advertisement 
$ curl -si http://git.kernel.org/pub/scm/git/git.git/info/refs?service=git-upload-pack | grep --binary-files=text '^Content-Type' 
Content-Type: application/x-git-upload-pack-advertisement 
$ curl -si http://repo.or.cz/r/git.git/info/refs?service=git-upload-pack | grep --binary-files=text '^Content-Type' 
Content-Type: text/plain 

(Pipe a grep -q "^Content-Type: application/x-git" y utilizar el código de retorno para la prueba de verdadero/falso.)

+0

También puede usar GIT_CURL_VERBOSE = 1 GIT_TRACE = 1 clon de git --verbose --depth 1 repo_url para usar el cliente git nativo en lugar de curl (que también maneja la autenticación en caso de repositorio privado) – kontulai

6

Creo que ya Git 1.8.2, se puede comprobar el encabezado Content-Type.
Por eso commit git/git/4656bf47 menciones:

Antes de analizar una sospecha de smart-respuesta HTTP verificar la Content-Type devuelto coincide con el estándar. Esto protege a un cliente de intentar procesar una carga útil que huele a una respuesta de servidor inteligente-HTTP.

Se puede ver un ejemplo de configuración de ese campo en comprometen sitaramc/gitolite/32d14d39:

my $service = ($ENV{SSH_ORIGINAL_COMMAND} =~ /git-receive-pack/ ? 'git-receive-pack' : 'git-upload-pack'); 

if ($service) { 
    print "Content-Type: application/x-$service-advertisement\r\n"; 
} 

lo tanto un campo de cabecera con Content-Typex-git-receive-pack-advertisement o x-git-upload-pack-advertisement significa http inteligente.

Cuestiones relacionadas