¿Cómo puedo asegurarme de que cuando clono, sincronizo y obtengo contenido de otro repositorio de anexo Git haya configurado un espejo idéntico?
He usado una herramienta como unison en el pasado que hacía una comparación de archivo a archivo, pero eso requiere mucho tiempo y memoria.
¿Existen otras alternativas para poder realizar una verificación de cordura? La principal motivación para esto es que acabo de hacer un clon de un repositorio existente y es más pequeño. Espero que sea más pequeño porque el repositorio antiguo tenía objetos sin usar o sin referencia, pero su tamaño es bastante diferente.
Entonces, me gustaría tener alguna verificación que pueda ejecutar.
Respuesta1
Git tiene una verificación de cordura incorporada ( git fsck) que señalaría problemas genéricos con la estructura de metadatos de git. También hay un recolector de basura ( git gc) que eliminaría cosas colgantes y otras cosas superfluas.
En cuanto a la integridad de los datos... básicamente esta es una garantía proporcionada por git, los datos que ingresas son los datos que obtienes. Si git log(o incluso solo el hash de la última confirmación) es idéntico, entonces también lo son los datos. Cada paso en git se suma de verificación, comparándolo con los datos, metadatos y lo anterior; Es como una cadena de bloques, si los datos cambiaran en algún lugar, las sumas de verificación también lo harían. Si las sumas de verificación no coincidieran, git se quejaría mucho al finalizar la compra.
Hay una vieja charla (¿2007-2008?) de Linus Torvalds sobre git que puedes ver en Youtube donde IIRC también habla sobre el lado de la integridad de los datos. También hay algo de documentación aquí:https://git-scm.com/book/en/Git-Internals-Git-Objects
En la práctica, la gente simplemente no se preocupa por esto ya que git mágicamente se encarga de ello. Simplemente haga 'git status' para ver si tiene que extraer/enviar/confirmar cambios para mantenerse al día con el origen.
El uso de espacio adicional también puede tener otras razones... git stashpuede ser un acaparador de espacio si alguna vez lo usó.
Aquí también es donde existen diferencias en los repositorios clonados: a git no le importan las cosas locales que nunca se confirmaron. Si no está comprometido, no existe en lo que respecta a los clones.
Respuesta2
Verifiqué que git anexo funciona como se esperaba haciendo lo siguiente:
- obtener una lista de archivos única y ordenada que incluya contenidos .git (esto garantiza que tengamos todos los contenidos del anexo de git)
- obtener una lista de enlaces única y ordenada que incluya contenidos .git (esto garantiza que tengamos la misma estructura de repositorio)
- comparar listados de archivos, ignorar el directorio de anexo/transferencia, los objetos git pueden ser diferentes, el contenido del anexo git debe ser idéntico
- comparar listados de enlaces, deben ser idénticos
- ejecute un git anexo fsck o compare la suma de comprobación de todos los archivos (esto es un problema del sistema de archivos)
Esto funciona, pero puede requerir un poco de trabajo y tiempo. Además, el proceso puede complicarse aún más si se tienen espejos que son sólo copias parciales. Para esos espejos, solo necesita comparar el contenido que espera tener.