Linus sugirió (ver a continuación la publicación completa de la lista de correo) usar git gc --aggressivesolo cuando tenga, en sus palabras, "un paquete realmente malo" o "deltas realmente horriblemente malos", sin embargo, "casi siempre, en otros casos, es realmente un mal cosas que hacer." ¡El resultado puede incluso dejar su repositorio en peores condiciones que cuando comenzó!
El comando que sugiere para hacer esto correctamente después de haber importado "una historia larga y complicada" es
Date: Wed, 5 Dec 2007 22:09:12 -0800 (PST)
From: Linus Torvalds <torvalds at linux-foundation dot org>
To: Daniel Berlin <dberlin at dberlin dot org>
cc: David Miller <davem at davemloft dot net>,
ismail at pardus dot org dot tr,
gcc at gcc dot gnu dot org,
git at vger dot kernel dot org
Subject: Re: Git and GCC
In-Reply-To: <4aca3dc20712052111o730f6fb6h7a329ee811a70f28@mail.gmail.com>
Message-ID: <alpine.LFD.0.9999.0712052132450.13796@woody.linux-foundation.org>
References: <4aca3dc20712051947t5fbbb383ua1727c652eb25d7e@mail.gmail.com>
<20071205.202047.58135920.davem@davemloft.net>
<4aca3dc20712052032n521c344cla07a5df1f2c26cb8@mail.gmail.com>
<20071205.204848.227521641.davem@davemloft.net>
<4aca3dc20712052111o730f6fb6h7a329ee811a70f28@mail.gmail.com>
El jueves 6 de diciembre de 2007, Daniel Berlin escribió:
En realidad, resulta que git-gc --aggressivehace esta tontería empacar archivos a veces, independientemente de si ha convertido de un repositorio SVN o no.
Absolutamente. git --aggressivees mayormente tonto. Realmente solo es útil para el caso de "Sé que tengo un paquete realmente malo y quiero deshacerme de todas las malas decisiones de empaque que he tomado".
Para explicar esto, vale la pena explicar (probablemente lo sepas, pero déjame repasar los conceptos básicos de todos modos) cómo funcionan las cadenas delta de git y cómo son tan diferentes de la mayoría de los otros sistemas.
En otros SCM, una cadena delta generalmente es fija. Puede ser "hacia adelante" o "hacia atrás" y puede evolucionar un poco a medida que trabaja con el repositorio, pero generalmente es una cadena de cambios en un solo archivo representado como algún tipo de entidad SCM única. En CVS, obviamente es el *,varchivo, y muchos otros sistemas hacen cosas bastante similares.
Git también hace cadenas delta, pero las hace mucho más "sueltas". No existe una entidad fija. Los deltas se generan contra cualquier otra versión aleatoria que git considere un buen candidato delta (con varias heurísticas bastante exitosas), y no hay absolutamente ninguna regla de agrupación estricta.
En general, esto es algo muy bueno. Es bueno por varias razones conceptuales ( es decir , git internamente nunca necesita preocuparse por toda la cadena de revisión, realmente no piensa en términos de deltas), pero también es genial porque deshacerse de las inflexibles reglas delta significa que git no tiene ningún problema al fusionar dos archivos, por ejemplo, simplemente no hay *,v“archivos de revisión” arbitrarios que tengan algún significado oculto.
También significa que la elección de deltas es una cuestión mucho más abierta. Si limita la cadena delta a un solo archivo, realmente no tiene muchas opciones sobre qué hacer con los deltas, pero en git, realmente puede ser un problema totalmente diferente.
Y aquí es donde --aggressiveentra en juego lo realmente mal llamado . Si bien git generalmente intenta reutilizar la información delta (porque es una buena idea, y no desperdicia el tiempo de la CPU para encontrar todos los deltas buenos que encontramos antes), a veces quiero decir "comencemos de nuevo, con una pizarra en blanco, ignoremos toda la información delta anterior e intente generar un nuevo conjunto de deltas".
Así --aggressiveque no se trata realmente de ser agresivo, sino de perder el tiempo de la CPU volviendo a tomar una decisión que ya tomamos antes.
A veces eso es bueno. Algunas herramientas de importación en particular podrían generar deltas realmente horriblemente malos. Cualquier cosa que use git fast-import, por ejemplo, probablemente no tenga un gran diseño delta, por lo que podría valer la pena decir "Quiero comenzar desde cero".
Pero casi siempre, en otros casos, es realmente algo realmente malo. Va a desperdiciar tiempo de CPU, y especialmente si realmente ha hecho un buen trabajo en deltaing antes, el resultado final no va a reutilizar todos esos buenos deltas que ya encontró, por lo que en realidad terminará con mucho peor resultado final también!
Enviaré un parche a Junio para eliminar la git gc --aggressive
documentación. Puede ser útil, pero generalmente es útil solo cuando realmente comprende a un nivel muy profundo lo que está haciendo, y esa documentación no lo ayuda a hacerlo.
Generalmente, hacer incrementos git gces el enfoque correcto y mejor que hacerlo git gc --aggressive. Va a reutilizar los deltas antiguos, y cuando no se puedan encontrar esos deltas antiguos (¡la razón para hacer GC incremental en primer lugar!), Creará otros nuevos.
Por otro lado, es definitivamente cierto que una "importación inicial de una historia larga y complicada" es un punto en el que puede valer la pena dedicar mucho tiempo a encontrar los deltas realmente buenos . Entonces, todos los usuarios posteriores (¡siempre que no lo git gc --aggressivedeshagan!) Obtendrán la ventaja de ese evento único. Entonces, especialmente para proyectos grandes con una larga historia, probablemente valga la pena hacer un trabajo adicional, diciéndole al código de búsqueda delta que se vuelva loco.
Entonces, el equivalente de git gc --aggressive, pero hecho correctamente , es hacer (durante la noche) algo como
git repack -a -d --depth=250 --window=250
donde esa profundidad se trata de cuán profundas pueden ser las cadenas delta (hazlas más largas para la historia antigua, vale la pena el espacio), y la cuestión de la ventana se trata de qué tan grande es la ventana de objeto que queremos que escanee cada candidato delta.
Y aquí, es posible que desee agregar la -fbandera (que es "eliminar todos los deltas antiguos", ya que ahora está tratando de asegurarse de que este realmente encuentre buenos candidatos.
Y luego tomará una eternidad y un día ( es decir , una cosa de "hazlo de la noche a la mañana"). Pero el resultado final es que todos los usuarios posteriores a ese repositorio obtendrán paquetes mucho mejores, sin tener que gastar ningún esfuerzo en ellos.
Linus