Cómo git fetch eficientemente desde un clon superficial
Usamos git para distribuir un sistema operativo y mantenerlo actualizado. No podemos distribuir el repositorio completo ya que es demasiado grande (>2GB), por lo que hemos estado usando clones poco profundos (~300M). Sin embargo recientemente, cuando se obtiene de un clon superficial, ahora se obtiene ineficientemente todo el repositorio >2GB. Este es un desperdicio insostenible de ancho de banda para las implementaciones.
La documentación de git dice que no se puede obtener desde un repositorio superficial, aunque eso no es estrictamente cierto. ¿Hay alguna solución alternativa para hacer un git clone --depth 1 capaz de recuperar lo que ha cambiado de él? ¿O alguna otra estrategia para mantener el tamaño de distribución lo más pequeño posible mientras tiene todos los bits que git necesita para hacer una actualización?
He intentado sin éxito clonar desde --depth 20 para ver si se actualizará de manera más eficiente, eso no funcionó. También investigué http://git-scm.com/docs/git-bundle , pero eso parece crear grandes paquetes.
5 answers
--depth es una opción git fetch. Veo que el documento realmente no resalta que git clone hace una búsqueda.
Cuando se obtiene, los dos repositorios intercambian información sobre quién tiene qué comenzando desde las cabezas del control remoto y buscando hacia atrás la confirmación compartida más reciente en los historiales de las referencias recuperadas, luego rellenando todos los objetos faltantes para completar solo las nuevas confirmaciones entre las confirmaciones compartidas más recientes y las recién recuperadas.
A --depth=1 fetch solo obtiene los consejos de rama y no previo historia. Otras búsquedas de esos historiales obtendrán todo lo nuevo mediante el procedimiento anterior, pero si las confirmaciones previamente obtenidas no están en el historial recién obtenido, fetch recuperará todo -- a menos que limite la búsqueda con --depth.
Su cliente hizo una búsqueda depth=1 de un repositorio y cambió las URL a un repositorio diferente. Al menos un largo camino de ascendencia en los refs de este nuevo repositorio aparentemente no comparte commits con nada actualmente en tu repositorio. Eso podría valer la pena investigar, pero de cualquier manera, a menos que haya alguna razón en particular, sus clientes pueden hacer cada fetch --depth=1.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-10-16 05:59:06
Acabo de hacerlo g clone github.com:torvalds/linux y me llevó mucho tiempo, así que me lo salté por CTRL+C.
Luego lo hizo g clone github.com:torvalds/linux --depth 1 y se clonó bastante rápido. Y solo tengo un commit en git log.
Así que clone --depth 1 debería funcionar. Si necesita actualizar el repositorio existente, debe usar git fetch origin branchname:branchname --depth 1. También funciona, solo obtiene un commit.
Resumiendo:
Clon inicial:
git clone git_url --depth 1
Actualización de código
git fetch origin branch:branch --depth 1
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-10-22 21:07:22
Tenga en cuenta que Git 1.9/2.0 (Q1 2014) podría ser más eficiente en la obtención de un clon superficial.
Ver cometer 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.
Todos los detalles están en "shallow.c: los 8 pasos para seleccionar nuevas confirmaciones para .git/shallow".
Puedes ver la consecuencia en commits como 0d7d285, f2c681c, y c29a7b8 que soportan clones, send-pack /receive-pack con/desde clones poco profundos.
smart-http ahora soporta shallow fetch / clone también .
Puedes incluso clonar un repositorio superficial .
Actualización 2015: git 2.5+ (Q2 2015) incluso permitirá un single commit fetch! Consulte " Extraer una confirmación específica de un repositorio git remoto".
Actualización de 2016 (Oct.): git 2.11+ (Q4 2016) permite buscar:
-
desde una fecha
--shallow-since=<date> -
con mayor profundidad :
--deepen=N
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:03:02
Si puede seleccionar una rama específica, puede ser aún más rápido. Aquí hay un ejemplo usando Spark master branch y latest tag:
Clon inicial
git clone [email protected]:apache/spark.git --branch master --single-branch --depth 1
Actualización a etiqueta específica
git fetch --depth 1 origin tags/v1.6.0
Se vuelve muy rápido cambiar etiquetas/rama de esta manera.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-01-07 16:39:41
No se si se ajusta a su configuración, pero lo que uso es tener un clon completo de ha de un repositorio en un directorio separado. Luego hago clon superficial desde el repositorio remoto con referencia al local.
git clone --depth 1 --reference /path/to/local/clone [email protected]/group/repo.git
De esta manera solo se obtienen las diferencias con el repositorio de referencia y el remoto. Para hacerlo aún más rápido puede usar la opción --shared, pero asegúrese de leer sobre las restricciones en la documentación git (puede ser peligroso).
También me enteré de que en en algunas circunstancias, cuando el control remoto ha cambiado mucho, el clon comienza a obtener demasiados datos. Es bueno romperlo entonces y actualizar el repositorio de referencia (que extrañamente toma mucho menos ancho de banda de lo que tomó en el primer lugar.) Y luego iniciar el clon de nuevo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-10-22 19:35:59