Entonces, el repositorio compartido de git parece ser más o menos perfecto para mantener sincronizadas carpetas con blobs grandes. Tengo algo así como 700 GB de imágenes y videos que quiero distribuir en mis computadoras, pero usar git sin ninguna otra adición resulta en una enorme sobrecarga de uso del disco que realmente no es necesaria.
Ahora, clonar con --shared (o -s) me da un repositorio git sin almacenamiento de objetos local (si lo entendí correctamente), que es más o menos lo que necesito. Sin embargo, la documentación comienza con "Cuando el repositorio a clonar está en la máquina local...". clone -s funciona igual de bien a través de SSH, pero eso me deja preguntándome qué sucede si el repositorio a clonar esnoen la máquina local. Como la documentación de -s comienza con esa oración, siento que todo el caso no está cubierto. ¿Hay algo que deba tener en cuenta excepto la eliminación de confirmaciones en el lado remoto que podría dar lugar a que ciertos objetos (que aún podrían estar en uso localmente) sean recolectados como basura? (lo cual no sucederá de todos modos, ya que quiero usar repositorios básicos en el servidor)
Respuesta1
Me encanta git, pero desafortunadamente, git no es la herramienta adecuada para esta tarea.
Git fue diseñado para mantener de manera muy eficiente el historial de cambios para repositorios de contenido principalmente de texto. Si bien git admite el mantenimiento de binarios, tendrá que mantenerlos para siempre en el historial para que pueda verificar cualquier revisión, lo cual es muy costoso en términos de espacio en disco.
Además, suponiendo que sus archivos binarios no sean comprimibles (imágenes, películas, música, etc.), el tamaño del almacén de objetos de git será aproximadamente el mismo que el del árbol de pago. En otras palabras, para 700 GB de archivos originales, el almacén de objetos ( .gitdirectorio) consumirá aproximadamente la misma cantidad y luego más cuando comience a comprometerse: agregar y eliminar contenido.
Puede utilizar el llamado clon superficial, que solo mantiene la última revisión del objeto en el almacén de objetos, pero los repositorios superficiales solo se pueden clonar, no comprometerse. En este caso, el repositorio maestro de git debe ser normal (no superficial) y seguirá siendo grande; sin embargo, todos los clones superficiales tendrán un tamaño razonable.
Probablemente le irá mejor si mantiene un esquema de sincronización más simple como rsync. Sin embargo, en ese caso perderás la posibilidad de revisar el historial; no hay almuerzo gratis :(
Respuesta2
Me doy cuenta de que esto no responde realmente a tu pregunta, pero... ¿no?sincronización¿Sería mucho más fácil mantener dos carpetas sincronizadas?