Cuando el repositorio a clonar de, esta en un equipo local, esta bandera sobrepasa el mecanismo de transporte normal "consciente de Git" y clona el repositorio haciendo una copia de HEAD y todo bajo los directorios de objetos y referencias. Los ficheros bajo el directorio .git/objects/ son vinculados para ahorrar espacio cuando es posible.

Forza el proceso de clonación desde un repositorio en un sistema de ficheros local para copiar los ficheros bajo el directorio .git/objects en lugar de usar hardlinks. Esto puede ser deseable si intentas hacer un respaldo de tu repositorio.

Cuando el repositorio a clonar esta en el equipo local, en lugar de usar hardlinks , automáticamente se configura .git/objects/info/alternates para compartir los objetos con el repositorio fuente. El repositorio resultante comienza sin tener algún objeto.

Si el repositorio referencia esta en el equipo local, automáticamente se configura .git/objects/info/alternates para obtener los objetos del repositorio referencia. Usando un repositorio ya existente como un alterno requerirá que menos objetos sean copiados del repositorio siendo clonado, reduciendo costos de red y almacenamiento local. Cuando se usa --reference-if-able, un directorio inexistente es saltado con una advertencia en lugar de abortar la clonación.

Toma prestados los objetos de repositorios referencia especificados con la opciones --reference sólo para reducir transferencias de red, y deja de tomarlos prestados de ellos después de clonar haciendo las copias locales necesarias de los objetos prestados. Esta opción también se puede usar cuando se clona localmente de un repositorio que ya toma objetos prestados de otro repositorio, el nuevo repositorio tomará prestados los objetos del mismo repositorio, y esta opción puede ser usada para dejar de tomar prestados.

Operar silenciosamente. El progreso no es reportado al flujo de error estándar.

Ejecutar verbosamente. No afecta el reporte de estado de progreso hacia el flujo de error estándar.

El estado de avance se indica en la salida de error estándar por defecto cuando esta está asociada a un terminal, a menos que se especifique --quiet. Esta bandera forza el estado de avance incluso cuando la salida de error estándar no es por terminal.

Transmite la cadena de caracteres dada al servidor cuando haya comunicación utilizando la versión 2 del protocolo. La cadena de caracteres dada no debe contener ningún carácter NUL ni LF. La gestión que el servidor hace de sus opciones, incluyendo las desconocidas, es específica de cada servidor. Cuando se dan múltiples --server-option=<opción>, todas ellas se envían al otro lado en el orden listado en la línea de comandos.

No hace checkout de HEAD después de completar la clonación.

Falla si la fuente del repositorio es un repositorio superficial. Se puede usar la variable de configuración clone.rejectShallow para especificar el valor predeterminado.

Hace un repositorio Git básico. Esto es, en lugar de crear <directorio> y colocar los ficheros administrativos en <directorio>/.git, hace al <directorio> mismo el $GIT_DIR. Esto implica obviamente el --no-checkout porque no hay dónde hacer checkout al árbol de trabajo. Además las heads de las ramas en el remoto son copiadas directamente a las heads de rama local correspondientes, sin mapearlas a refs/remotes/origin/. Cuando se usa esta opción, no se crean ni las ramas de seguimiento remoto ni las variables de configuración relacionadas.

Emplea un checkout -escaso, sólo con los ficheros en el nivel superior del directorio que esten presentes inicialmente. Se puede usar el comando git-sparse-checkout[1] para crecer el directorio de trabajo cuando se necesite.

Usa la característica de clonado parcial y solicita que el servidor envíe un subconjunto de objetos alcanzables conforme a un filtro de objetos dado. Cuando se usa --filter la <especificación-de-filtro> dada se usa para el filtro de clonado parcial. Por ejemplo, --filter=blob:none filtrará todos los blobs (contenido del fichero) hasta que lo necesite Git. También --filter=blob:limit=<tamaño> filtrará todos los blobs cuyo tamaño sea por lo menos <tamaño>. Para mas detalles sobre especificaciones de filtros ver la opción --filter en git-rev-list[1].

Además aplica el filtro de clonación parcial a cualquier submódulo en el repositorio. Requiere --filter y --recurse-submodules. Esto puede habilitarse de forma predeterminada configurando la opción de configuración clone.filterSubmodules.

Configura un espejo del repositorio fuente. Esto implica --bare. Comparado con --bare, --mirror no solo mapea ramas locales de la fuente a ramas locales en el objetivo, mapea todas las referencias (incluyendo ramas de seguimiento-remoto, notas, etc.) y configura una especificación de referencia de tal manera que todas las referencias sean sobre-escritas por un git remote update en repositorio objetivo.

En lugar de usar el nombre remoto origin para dar seguimiento al repositorio upstream, usa <nombre>. Sobremonta clone.defaultRemoteName de la configuración.

En lugar de apuntar la HEAD recientemente creada a la rama a la que apunta HEAD del repositorio clonado, apunta a la rama <nombre>. En un repositorio no-básico, a esta rama se le hará checkout. --branch también puede tomar etiquetas y soltar la HEAD en ese commit en el repositorio resultante.

Cuando se proporciona, y el repositorio a clonar se accesa por ssh, este especifica una ruta no predeterminada para la ejecución del comando en el otro extremo.

Especifica el directorio de donde se usarán las plantillas; (Ver la sección "DIRECTORIO DE PLANTILLAS" de git-init[1].)

Asigna una variable de configuración en el repositorio recientemente creado; este surte efecto inmediatamente después de que el repositorio es inicializado, pero antes de que el historial remoto sea traído o de que se les haga checkout a los ficheros. La clave es en el mismo formato que espera git-config[1] (ej. core.eol=true). Si se proporcionan múltiples valores para la misma clave, cada valor se escribirá en el fichero de configuración. Esto hace seguro, por ejemplo, agregar especificaciones de referencia de fetch adicionales al origen remoto.

Crea un clon superficial con un historial truncado al número especificado de commits. Implica --single-branch a menos que se ponga --no-single-branch para traer historias cercanas a las puntas de todas las ramas. Si quieres clonar sub-módulos superficialmente, también pon --shallow-submodules.

Crear un clon superficial con historial posterior al tiempo especificado.

Crear un clon superficial con historial excluyendo commits alcanzables desde una rama remota o etiqueta especificada. Esta opción puede ser especificada múltiples veces.

Clona únicamente el historial hacia la punta de una sola rama, ya sea especificada por la opción --branch o por hacia donde apunte HEAD de la rama remota. Fetchs posteriores en el repositorio resultante sólo actualizarán la rama de seguimiento remoto para la rama en la que se usó ésta opción en la clonación inicial. Si la HEAD en el remoto no apuntó a alguna rama cuando se hizo la clonación --single-branch, no se crea rama de seguimiento remoto.

No clona ninguna etiqueta y define remote.<remote>.tagOpt=--no-tags en la configuración, lo que garantiza que futuras ejecuciones de git pull y git fetch no seguirán ninguna etiqueta. Aún funcionarán las capturas de etiquetas explícitas que se realicen en el futuro (consulte git-fetch[1]).

Después de crear el clon, inicializa y clona sub-módulos con base en la especificación de ruta proporcionada. Si no se da una especificación de ruta, todos los sub-módulos son inicializados y clonados. Esta opción se puede dar múltiples veces para especificaciones de ruta consistentes en múltiples entradas. El clon resultante tendrá submodule.active configurado con la especificación de ruta proporcionada, o con "." (que significa todos los sub-módulos) si no se proporciona.

Todos los sub-módulos clonados serán superficiales con profundidad 1.

Todos los sub-módulos clonados usarán el estatus de la rama de seguimiento-remoto del sub-módulo para actualizar el sub-módulo, en lugar del SHA-1 registrado en el super-proyecto. Equivalente a pasar --remote en git submodule update.

En lugar de colocar el repositorio clonado donde se supone, se coloca en el directorio especificado, y luego se hace hacia él una liga simbólica Git agnóstica de sistema de ficheros. El resultado es que el repositorio Git puede ser separado del árbol de trabajo.

Especifica el formato de almacenamiento de referencia dado para el repositorio. Los valores válidos son:

La cantidad de submódulos obtenidos al mismo tiempo. Por defecto usa el valor de la opción submodule.fetchJobs.

El repositorio (posiblemente remoto) a clonar desde. Ver la sección URLS GIT a continuación para mas información sobre la especificación de repositorios.

El nombre de un nuevo directorio para clonar hacia. Se usa la parte "humanizada" del repositorio fuente si no se da explícitamente un directorio (repo para /ruta/a/repo.git y foo para host.xz:foo/.git). Sólo se permite clonar a un directorio existente si el directorio está vacío.

Antes de hacer fetch de un remoto, trae un empaquetado de una <uri>`dada y desempaqueta los datos en el repositorio local. Las referencias en el empaquetado se almacenarán bajo el espacio de nombres oculto `refs/bundle/*. Esta opción es incompatible con --depth, --shallow-since y --shallow-exclude.