performance - gratis - ¿Es seguro realizar clones superficiales con--depth 1, crear confirmaciones y volver a obtener actualizaciones?

forzar actualizacion gmail

Question

La opción --depth 1 en git clone :

Cree un clon superficial con un historial truncado al número especificado de revisiones. Un repositorio de poca profundidad tiene una serie de limitaciones (no puede clonarlo ni obtener nada de él, ni puede insertarlo ni forzarlo), pero es adecuado si solo está interesado en la historia reciente de un proyecto grande con un largo historial, y desearía Enviar correcciones como parches.

Pero hice con éxito un clon superficial, cometí algunos cambios y devolví esos cambios al origen (clon simple).

Tiene sentido para mí, quiero decir, ¿por qué no? Cuando la CABEZA clonada es identificable en el origen, y mi compromiso se suma a esto, no parece haber ninguna razón. Pero el manual dice lo contrario.

Me gusta la idea de un clon superficial, por ejemplo, del núcleo drupal: no hay forma de que necesite saber qué sucedió en el drupal 4 cuando comencé desde el 7, pero no quiero dispararme en el pie.

Entonces, ¿es seguro hacer clones superficiales, desarrollar compromisos en él, volver a jalar para mantenerse al día con las actualizaciones desde el origen?

Answer 1

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 debe a los compromisos como 0d7d285 , f2c681c y c29a7b8 que admiten clones, paquetes de envío / paquetes de recepción con / desde clones poco profundos.
smart-http ahora soporta también captura / clonación superficial .

Todos los detalles se encuentran 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 un solo compromiso !
(Ultimo caso poco profundo)

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) de Stephen P. Smith (``) .
^{(Fusionada por Junio ​​C Hamano - gitster - in commit 7e3e80a , 20 de enero de 2016)}

Esto es " Documentation/user-manual.txt "

Se <<def_shallow_clone,shallow clone>> un <<def_shallow_clone,shallow clone>> especificando el git-clone --depth .
La profundidad se puede cambiar posteriormente con el interruptor git-fetch --depth , o se puede restaurar el historial completo con --unshallow .

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

Para obtener más información sobre el proceso de actualización de clones poco profundos, consulte " ¿Cómo actualizar un git shallon clone? ".

Como comentó Richard Michael :

para rellenar la historia: git pull --unshallow

Y Olle Härstedt agrega en los comentarios :

Para rellenar parte del historial: git fetch --depth=100 .

Answer 2

Vea algunas de las respuestas a mi pregunta similar why-cant-i-push-from-a-shallow-clone y el enlace al hilo reciente en la lista de git.

En última instancia, la medición de ''profundidad'' no es consistente entre los repos, porque miden desde sus CABEZAS individuales, en lugar de (a) su Cabeza, o (b) los comités (s) que clonó / ​​buscó, o (c) algo más lo tenias en mente

Lo difícil es acertar en el caso de uso (es decir, autoconsistente), de modo que los repositorios distribuidos, y por lo tanto, probablemente divergentes, aún funcionarán felices juntos.

Parece que la checkout --orphan es la etapa de ''configuración'' correcta, pero aún carece de una guía clara (es decir, un comando de una línea simple y comprensible) en el paso de "clonación". Más bien parece que tienes que init un repositorio, configurar una rama de seguimiento remote (¿quieres solo una rama?), Y luego fetch esa única rama, que se siente mucho tiempo con más oportunidades de errores.

Edición: para el paso ''clon'' vea esta respuesta