¿Es seguro clonar superficialmente con --depth 1, crear confirmaciones y volver a obtener actualizaciones?

La --depth 1opción engit clone :

Cree un clon superficial con un historial truncado al número especificado de revisiones. Un repositorio poco profundo tiene una serie de limitaciones (no se puede clonar ni extraer de él, ni empujar ni entrar en él), pero es adecuado si solo está interesado en la historia reciente de un gran proyecto con una larga historia y desea enviar arreglos como parches.

Pero he realizado con éxito un clon superficial, cometí algunos cambios y los devolví al origen (clon desnudo).

Tiene sentido para mí. Quiero decir, ¿por qué no? cuando la CABEZA clonada es identificable en el origen, y mi confirmación se suma a esto, parece que no hay razón. Pero el manual dice lo contrario.

Me gusta la idea del clon superficial, por ejemplo, del núcleo de drupal: de ninguna manera necesito saber qué sucedió en drupal 4 cuando comencé desde 7. - pero no quiero pegarme un tiro en el pie.

Entonces, ¿es seguro clonar poco profundo, desarrollar commits en él, volver a tirar para mantenerse al día con las actualizaciones desde el origen?

Tenga en cuenta que Git 1.9 / 2.0 (Q1 2014) ha eliminado esa limitación.
Ver commit 82fba2b , de Nguyễn Thái Ngọc Duy ( pclouds) :

Ahora que git admite la transferencia de datos desde o hacia un clon superficial, estas limitaciones ya no son ciertas.

La documentación ahora lee :

--depth <depth>::

Cree un clon 'superficial' con un historial truncado al número especificado de revisiones.

Eso se deriva de confirmaciones como 0d7d285 , f2c681c y c29a7b8 que admiten clones, paquetes de envío / paquete de recepción con / desde clones superficiales.
smart-http ahora también admite búsqueda / clonación superficial .

Todos los detalles están en " shallow.c: los 8 pasos para seleccionar nuevas confirmaciones para.git/shallow ".

Actualización de junio de 2015: ¡ Git 2.5 incluso permitirá recuperar una sola confirmación !
(Último caso superficial)

Actualización de enero de 2016: Git 2.8 (Mach 2016) ahora documenta oficialmente la práctica de obtener un historial mínimo.
Consulte commit 99487cf , commit 9cfde9e (30 de diciembre de 2015), commit 9cfde9e (30 de diciembre de 2015), commit bac5874 (29 de diciembre de 2015) y commit 1de2e44 (28 de diciembre de 2015) por Stephen P. Smith (``) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 7e3e80a , 20 de enero de 2016)}

Esto es " Documentation/user-manual.txt"

A <<def_shallow_clone,shallow clone>>se crea especificando el git-clone --depthinterruptor.
La profundidad se puede cambiar más tarde con el git-fetch --depthinterruptor, o se puede restaurar el historial completo con --unshallow.

Fusionarse dentro de un <<def_shallow_clone,shallow clone>>funcionará siempre que una base de fusión esté en la historia reciente.
De lo contrario, será como fusionar historias no relacionadas y puede dar lugar a grandes conflictos.
Esta limitación puede hacer que dicho repositorio sea inadecuado para usarse en flujos de trabajo basados ​​en fusión.

Actualización 2020:

• git 2.11.1 introdujo la opción git fetch --shallow-exclude=para evitar recuperar todo el historial
• git 2.11.1 introdujo la opción git fetch --shallow-since=para evitar recuperar confirmaciones antiguas.

Para obtener más información sobre el proceso de actualización de clones superficiales, consulte " ¿Cómo actualizar un clon superficial de git? ".

Como comentó Richard Michael :

para rellenar el historial: git pull --unshallow

Y Olle Härstedt agrega en los comentarios :

Para rellenar parte de la historia: git fetch --depth=100.

Vea algunas de las respuestas a mi pregunta similar: ¿ por qué no puedo empujar desde un clon poco profundo? y el enlace al hilo reciente en la lista de git.

En última instancia, la medición de 'profundidad' no es consistente entre repos, porque miden desde sus HEAD individuales, en lugar de (a) su Head, o (b) el commit (s) que clonó / ​​obtuvo, o (c) otra cosa Tenías en mente.

Lo difícil es obtener el caso de uso correcto (es decir, autoconsistente), de modo que los repositorios distribuidos y, por lo tanto, probablemente divergentes, sigan funcionando juntos de manera feliz.

Parece que checkout --orphanes la etapa correcta de "configuración", pero aún carece de una guía limpia (es decir, un simple comando comprensible de una línea) sobre el paso "clonar". Más bien parece que tiene que hacer initun repositorio, configure una remoterama de seguimiento (¿solo quiere una rama?), Y luego fetchesa rama única, que se siente sin aliento con más oportunidades de errores.

Editar: para el paso 'clonar', vea esta respuesta