¿Cuál es el propósito de los repositorys de GIT desnudos en .repo / projects / creados por el script de repos de Android?

La fuente de Android es administrada por repo . Cuando se sincroniza usando repo, se crea un directory llamado .repo/projects/ , que contiene todos los repositorys de git también desprotegidos directamente en el directory de trabajo actual, simplemente en formatting bare git.

¿Para qué sirve repo mantener los repositorys de git al descubierto? ¿Y cómo son estos repositorys simples utilizados por repo?

(NB: Aclaración: no estoy hablando de un repository de git cuando escribo "repo", estoy hablando específicamente del script llamado repo creado por / para Android para mantener todos los repositorys de git que comprenden la fuente de Android).

Después de trabajar con el sistema de manifiesto de repos de Android por un time, creo que ahora entiendo el propósito de los repositorys en el .repo/projects/ .

Como ya respondió @Fnetworkingrik, los proyectos no son otra copy de los repositorys representados directamente en el "clon" creado por repo . De hecho, el contenido de todos los directorys .git en el clon son solo enlaces simbólicos, como este:

 $ ll development/.git/ total 452 drwxr-xr-x 2 bfh bfh 4096 2011-08-15 13:55 ./ drwxr-xr-x 20 bfh bfh 4096 2011-08-15 13:55 ../ lrwxrwxrwx 1 bfh bfh 43 2011-08-15 13:55 config -> ../../.repo/projects/development.git/config lrwxrwxrwx 1 bfh bfh 48 2011-08-15 13:55 description -> ../../.repo/projects/development.git/description -rw-r--r-- 1 bfh bfh 41 2011-08-15 13:55 HEAD lrwxrwxrwx 1 bfh bfh 42 2011-08-15 13:55 hooks -> ../../.repo/projects/development.git/hooks/ -rw-r--r-- 1 bfh bfh 449008 2011-08-15 13:55 index lrwxrwxrwx 1 bfh bfh 41 2011-08-15 13:55 info -> ../../.repo/projects/development.git/info/ lrwxrwxrwx 1 bfh bfh 41 2011-08-15 13:55 logs -> ../../.repo/projects/development.git/logs/ lrwxrwxrwx 1 bfh bfh 44 2011-08-15 13:55 objects -> ../../.repo/projects/development.git/objects/ lrwxrwxrwx 1 bfh bfh 48 2011-08-15 13:55 packed-refs -> ../../.repo/projects/development.git/packed-refs lrwxrwxrwx 1 bfh bfh 41 2011-08-15 13:55 refs -> ../../.repo/projects/development.git/refs/ lrwxrwxrwx 1 bfh bfh 45 2011-08-15 13:55 rr-cache -> ../../.repo/projects/development.git/rr-cache/ lrwxrwxrwx 1 bfh bfh 40 2011-08-15 13:55 svn -> ../../.repo/projects/development.git/svn 

Por lo tanto, los repositorys git reales solo se representan una vez en un clon.

La razón para mantener un git normal y desnudo se debe a la forma en que funciona el sistema manifiesto. El sistema de manifiestos es una forma de especificar una colección de gits que serán revisados, y en qué versión serán revisados. El file de manifiesto se mantiene en un git, y el command repo permite cambiar la twig de ese git de manifiesto como lo desee.

Por lo tanto, para permitir una forma (rápida) de eliminar y agregar gits en function de lo que se selecciona actualmente en el file de manifiesto, repo puede mantener todos los gits que haya clonado en la carpeta .repo/projects y luego solo copyrlos en el .repo/projects área de clonación "normal" si se eligen en la twig actual del file de manifiesto.

No son dos copys, la carpeta .git en un componente contiene enlaces simbólicos hacia el componente correspondiente en ./repo/projects

Descargo de responsabilidad: estoy lejos de ser un experto con Git.

Creo que estás diciendo que cuando compras el código obtienes dos copys. Una es la copy de trabajo (donde se especificó que se debe copyr) y otra se guarda en .repo / projects. Suponiendo que he interpretado la pregunta correctamente, mi mejor opción sería que la copy en .repo / projects se guarde para que puedas hacer comparaciones rápidamente y volver a la revisión base que sacaste sin tener que volver al server. Creo que es bastante común que los VCS hagan eso. SVN lo hace colocando una carpeta .svn en todas las carpetas de su copy de trabajo y colocando los files de revisión base en ellas.