Ahora el mismo archivo 'enorme' reside en ambas bifurcaciones del desarrollador en el servidor. No crea un enlace duro automáticamente
En realidad, con Git 2.20, ese problema podría desaparecer debido a las islas delta. , una nueva forma de realizar cálculos delta para que un objeto que existe en una bifurcación no se convierta en un delta contra otro objeto que no aparece en el mismo repositorio bifurcado .
Ver commit fe0ac2f, commit 108f530, commit f64ba53 (16 de agosto de 2018) por Christian Couder (chriscool ).
Ayudado por:Jeff King (peff ) y Duy Nguyen (pclouds ).
Ver confirmación 9eb0986, confirmación 16d75fa, confirmación 28b8a73, confirmación c8d521f (16 de agosto de 2018) por Jeff King (peff ).
Ayudado por:Jeff King (peff ), y Duy Nguyen (pclouds ).
Agregar delta-islands.{c,h}
Los proveedores de alojamiento que permiten a los usuarios "bifurcar" los repositorios existentes quieren que esas bifurcaciones compartan tanto espacio en disco como sea posible.
Las alternativas son una solución existente para mantener todos los objetos de todas las bifurcaciones en un repositorio central único, pero esto puede tener algunos inconvenientes.
Especialmente al empaquetar el repositorio central, se crearán deltas entre objetos de diferentes bifurcaciones.
Esto puede hacer que la clonación o la recuperación de una bifurcación sea mucho más lenta y requiera mucha más CPU, ya que Git podría tener que calcular nuevos deltas para muchos objetos para evitar enviar objetos desde una bifurcación diferente.
Debido a que la ineficiencia surge principalmente cuando un objeto se deltifica contra otro objeto que no existe en la misma bifurcación, dividimos los objetos en conjuntos que aparecen en la misma bifurcación y definimos "islas delta".
Al encontrar la base delta, no permitimos que un objeto fuera de la misma isla se considere como su base.
Entonces, las "islas delta" son una forma de almacenar objetos de diferentes bifurcaciones en el mismo repositorio y archivo de paquete sin tener deltas entre objetos de diferentes bifurcaciones.
Este parche implementa el mecanismo de islas delta en "delta-islands.{c,h} ", pero aún no hace uso de él.
Se agregaron algunos campos nuevos en 'struct object_entry ' en "pack-objects.h " aunque.
Ver Documentation/git-pack-objects.txt :Isla Delta:
ISLAS DELTA
Cuando sea posible, pack-objects intenta reutilizar los deltas existentes en el disco para evitar tener que buscar nuevos sobre la marcha. Esta es una optimización importante para realizar recuperaciones, porque significa que el servidor puede evitar inflar la mayoría de los objetos y simplemente enviar los bytes directamente desde el disco.
Esta optimización no puede funcionar cuando un objeto se almacena como un delta contra una base que el receptor no tiene (y que aún no estamos enviando). En ese caso, el servidor "rompe" el delta y tiene que encontrar uno nuevo, lo que tiene un alto costo de CPU. Por lo tanto, es importante para el rendimiento que el conjunto de objetos en las relaciones delta en disco coincida con lo que buscaría un cliente.
En un repositorio normal, esto tiende a funcionar automáticamente.
La mayoría de los objetos son accesibles desde las ramas y las etiquetas, y eso es lo que buscan los clientes. Es probable que cualquier delta que encontremos en el servidor esté entre los objetos que el cliente tiene o tendrá.
Pero en algunas configuraciones de repositorio, puede tener varios grupos relacionados pero separados de consejos de referencia, y los clientes tienden a obtener esos grupos de forma independiente.
Por ejemplo, imagine que aloja varias "bifurcaciones" de un repositorio en un solo almacén de objetos compartidos y permite que los clientes los vean como repositorios separados a través de GIT_NAMESPACE o repositorios separados mediante el mecanismo alternativo.
Un reempaquetado ingenuo puede encontrar que el delta óptimo para un objeto está contra una base que solo se encuentra en otra bifurcación.
Pero cuando un cliente busca, no tendrá el objeto base y tendremos que encontrar un nuevo delta sobre la marcha.
Puede existir una situación similar si tiene muchas referencias fuera de refs/heads/ y refs/tags/ que apuntan a objetos relacionados (por ejemplo, refs/pull o refs/changes utilizado por algunos proveedores de alojamiento). De forma predeterminada, los clientes obtienen solo encabezados y etiquetas, y los deltas contra los objetos que se encuentran solo en esos otros grupos no se pueden enviar tal cual.
Las islas Delta resuelven este problema al permitirle agrupar sus referencias en distintas "islas" .
Pack-objects calcula qué objetos son accesibles desde qué islas y se niega a hacer un delta a partir de un objeto A contra una base que no está presente en todos los A islas de . Esto da como resultado paquetes ligeramente más grandes (porque perdemos algunas oportunidades delta), pero garantiza que una búsqueda de una isla no tendrá que volver a calcular los deltas sobre la marcha debido al cruce de los límites de la isla.
Sin embargo, un efecto secundario:algunos comandos eran más detallados. Git 2.23 (Q3 2019) corrige esto.
Consulte la confirmación bdbdf42 (20 de junio de 2019) de Jeff King (peff) ).
delta-islands :respeto progress bandera
El código de isla delta siempre imprime "Marked %d islands ", incluso si el progreso se ha suprimido con --no-progress o enviando stderr a un no tty.
Pasemos un progress booleano a load_delta_islands() .
Ya hicimos lo mismo para el medidor de progreso en resolve_tree_islands() .
He decidido hacer esto:
shared-objects-database.git/
foo.git/
objects/info/alternate (will have ../../shared-objects-database.git/objects)
bar.git/
objects/info/alternate (will have ../../shared-objects-database.git/objects)
baz.git/
objects/info/alternate (will have ../../shared-objects-database.git/objects)
Todas las bifurcaciones tendrán una entrada en su archivo de objetos/información/alternativas que brinda una ruta relativa al repositorio de la base de datos de los objetos.
Es importante convertir la base de datos de objetos en un repositorio, porque podemos guardar objetos y referencias de diferentes usuarios que tengan un repositorio con el mismo nombre.
Pasos:
git init --bare shared-object-database.git-
Ejecuto las siguientes líneas de código cada vez que hay un impulso a cualquier bifurcación (a través de la recepción posterior) o ejecutando un cronjob
for r in list-of-forks do(cd "$r" &&git push ../shared-objects-database.git "refs/:refs/remotes/$r/ " &&echo ../../shared-objects-database.git/objects>objects/info/alternates# para guardar. Agrego los objetos "gruesos" a las alternativas cada vez) hecho
Luego, en el siguiente "git gc" se eliminarán todos los objetos en bifurcaciones que ya existen en forma alternativa.
git repack -adl ¡también es una opción!
De esta manera, ahorramos espacio para que dos usuarios que inserten los mismos datos en sus respectivas bifurcaciones en el servidor compartan los objetos.
Necesitamos establecer el gc.pruneExpire variable hasta never en la base de datos de objetos compartidos. ¡Solo para estar seguro!
Para podar objetos ocasionalmente, agregue todas las bifurcaciones como controles remotos para compartir, buscar y podar. ¡Git hará el resto!
(¡Finalmente encontré una solución que funciona para mí! (¡No probado en producción! :p Gracias a esta publicación).