¿Cómo se puede usar con security una database de objects compartidos en git?

He leído en varios lugares que es posible compartir el directory de objects entre múltiples repositorys git, por ejemplo, con enlaces simbólicos. Me gustaría hacer esto para compartir las bases de datos de objects entre varios repositorys en el mismo directory:

 shanetworking-objects-database/ foo.git/ objects -> ../shanetworking-objects-database bar.git/ objects -> ../shanetworking-objects-database baz.git/ objects -> ../shanetworking-objects-database 

(Estoy haciendo esto porque de lo contrario se almacenarán muchos blobs grandes de forma networkingundante en cada directory de objects).

Mi preocupación al respecto es que al usar estos repositorys, se llamará automáticamente a git gc y hará que se poden los objects que son inalcanzables de un repository, haciendo que los otros repositorys estén incompletos. ¿Hay alguna forma fácil de garantizar que esto no ocurra? Por ejemplo, ¿existe una opción de configuration que obligue a --no-prune a ser el valor pnetworkingeterminado para git gc , y, de ser así, sería suficiente para usar esta configuration sin correr el riesgo de perder datos?

Por el momento, he estado usando el mecanismo objects/info/alternates para compartir objects entre estos repositorys, pero el mantenimiento de estos pointers desde cada repository a todos los demás es un poco hacky.

(Mi otra alternativa es simplemente tener un solo repository vacío, con todas las twigs de foo.git , bar.git y baz.git llamadas foo-master , foo-testing , bar-master , etc. Sin embargo, eso Sería un poco más difícil de gestionar, así que si el directory de objects enlazados puede funcionar de manera segura, prefiero hacerlo.

Puede adivinar que este es uno de esos casos de uso de Git para lo que no era intencionado, pero espero que la pregunta sea clara y válida;)

Solutions Collecting From Web of "¿Cómo se puede usar con security una database de objects compartidos en git?"

¿Por qué no acaba de poner la variable gc.pruneExpire hasta never ? Es poco probable que tengas objects sueltos de 1000 años que no quieras eliminar.

Para asegurarse de que las cosas que realmente deben ser podadas se eliminen, puede mantener un repository que tenga todos los demás como controles remotos. git gc sería bastante seguro en eso, ya que realmente sabe lo que es inalcanzable.

Editar: Bien, era un poco arrogante sobre el límite de time; como se señala en los comentarios, 1000 años no van a funcionar demasiado bien, pero el comienzo de la época sería, o never .

Quizás esto se agregó a git después de que se hizo / contestó esta pregunta: parece que ahora hay una manera de hacer esto explícitamente. Se describe aquí:

https://git.wiki.kernel.org/index.php/Git_FAQ#How_to_share_objects_between_existing_repositories.3F

¿Cómo compartir objects entre repositorys existentes? Hacer

 echo "/source/git/project/.git/objects/" > .git/objects/info/alternates 

y luego seguirlo con

 git repack -a -d -l 

donde -l significa que solo colocará objects '' locales '' en el file de package (estrictamente hablando, también pondrá cualquier object suelto del tree alternativo, por lo que tendrá un file completamente empaquetado, pero ganó 'duplicar objects que ya están empaquetados en el tree alternativo).