¿Cuál es el propósito de los repositorios git desnudos en .repo / projects / creados por el script de repo de Android?
La fuente de Android se gestiona mediante repo . Cuando se sincroniza con repo, se crea un directorio llamado .repo/projects/ , que contiene todos los repositorios git que también se descargan directamente en el directorio de trabajo actual, sólo en formato git.
¿Con qué propósito repo mantiene los depósitos git desnudos? ¿Y cómo se utilizan estos repositorios desnudos por repo?
- Error de instalación ADT
- Dónde y por qué añadir repositorios en build.gradle
- Android Studio Git .gitignore vs Proyecto> Configuración> Control de versiones> Archivos ignorados
- Recursos de aprendizaje para Android Open Source Project (AOSP)
- Importar biblioteca en Eclipse sin jar
(Nota: No estoy hablando de un repositorio git cuando escribo "repo", estoy hablando específicamente del script llamado repo creado por / para Android para mantener todos los repositorios git que componen la fuente de Android).
- Importación de apklib desde github con Maven
- Pausar y reanudar la sincronización de Android Repo
- ¿Cómo funciona git push con la herramienta de repo de android?
- Android Studio Error: (3, 0) No se encontró el complemento con id 'com.android.application'
- Sincronización de errores con cyanogenmod repo
- Android Studio Cómo enviar al nuevo repositorio
Después de trabajar con el sistema de manifiesto repo de Android por un tiempo, creo que ahora entiendo el propósito de los repositorios desnudos en el .repo/projects/ .
Como ya han respondido @Fredrik los proyectos no hay otra copia de los repositorios representados directamente en el "clon" creado por el repo . De hecho, el contenido de todos los directorios .git en el clon son simplemente enlaces simbólicos, como esto:
$ 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
Así, los repositorios git reales sólo se representan una vez en un clon.
La razón para mantener un desnudo y un git normal son entonces debido a la forma en que funciona el sistema de manifiesto. El sistema de manifiesto es una forma de especificar una colección de gits que se descartarán y en qué versión se descartarán. El archivo de manifiesto se mantiene en un git, y el comando de repo permite cambiar la rama de ese git de manifiesto como quieras.
Por lo tanto, para permitir una manera (rápida) de eliminar y agregar gits dependiendo de lo que actualmente se escoge en el archivo de manifiesto, el repo sólo puede mantener todos los gits que haya clonado en la carpeta .repo/projects y luego sólo copiarlos en el .repo/projects "Normal" si son elegidos en la rama actual del archivo de manifiesto.
No es dos copias, la carpeta .git de un componente contiene enlaces simbólicos hacia el componente correspondiente en ./repo/projects
Exención de responsabilidad: Estoy lejos de ser un experto con Git.
Creo que estás diciendo que cuando sales del código recibes dos copias. Uno es la copia de trabajo (donde se especificó que se debe copiar a) y otro se mantiene en .repo / proyectos. Suponiendo que he interpretado la pregunta correctamente, mi mejor conjetura sería que la copia en .repo / projects se mantiene para que usted pueda hacer rápidamente comparaciones con y volver a la revisión de base que se retiró sin tener que volver al servidor. Creo que es muy común que los VCSs lo hagan. SVN lo hace poniendo una carpeta .svn en todas las carpetas de su copia de trabajo y poniendo los archivos de revisión base en ellos.