repo init un commit particular

Estoy construyendo el sistema Cyanogenmod 9 (Android ICS) para un teléfono Nexus S (samsung crespo). El problema es que si lo hago:

repo init -u git://github.com/CyanogenMod/android.git -b ics 

El repo entra en la última confirmación de ICS, en la que el manifiesto no incluye algunos dispositivos / samsung / proyectos que necesito (específicamente https://github.com/CyanogenMod/android_device_samsung_crespo ).

¿Cómo reinicio de un compromiso en particular? En mi caso, quiero la última confirmación utilizando la twig google android-4.0.3_r1. Es este:

  • https://github.com/CyanogenMod/android/commit/5f5da775f570f2995c8ff2db98e6c8b40852911c

Si lo hago

repo init -u git: //github.com/CyanogenMod/android.git -b commit-hash

No funciona, parece que repo init -b solo admite el HEAD de una twig.

Gracias por adelantado.

Respuesta larga:

No puede especificar un nombre de twig (o SHA, o lo que sea) para repo , no funcionará. Este es el por qué:

repo es un script que maneja una colección de proyectos de repository (que de hecho son git's independientes). La list de proyectos se encuentra en .repo git, y contiene un file de manifiesto, que básicamente es una list de todos los git del repository y sus twigs. -b es relevante solo para repo git durante el repo init .

Aquí hay un ejemplo de .repo/manifests/default.xml :

 <?xml version="1.0" encoding="UTF-8"?> <manifest> <remote fetch="git://address.com/" name="origin" review="review.address.com"/> <default remote="origin" revision="ics-something" sync-j="4"/> <manifest-server url="http://manifests.address.com:8000"/> <!-- sniff --> <project name="platform/external/libxml2" path="external/libxml2" revision="ics-common"/> <project name="platform/external/zlib" path="external/zlib" revision="ics-common"/> <project name="platform/frameworks/base" path="frameworks/base" revision="ics-something"/> <project name="platform/packages/apps/Bluetooth" path="packages/apps/Bluetooth" revision="ics-common"/> <!-- sniff --> </manifest> 

Entonces, la forma correcta de get las fonts del repository para la construcción particular es get su manifiesto.
Es decir, manifiesto, que contendrá SHA (o tags, que son prácticamente las mismas, si están presentes) en lugar de nombres de twig. De esta forma, cada proyecto de git dentro de su repository señalará algún compromiso, que fue el último más grande cuando se ejecutó la compilation:

 <?xml version="1.0" encoding="UTF-8"?> <manifest> <remote fetch="git://address.com/" name="origin" review="review.address.com"/> <default remote="origin" revision="ics-something" sync-j="4"/> <manifest-server url="http://manifests.address.com:8000"/> <!-- sniff --> <project name="platform/external/libxml2" path="external/libxml2" revision="refs/tags/android-4.0.4_r1.1"/> <project name="platform/external/zlib" path="external/zlib" revision="refs/tags/android-4.0.4_r1.1"/> <project name="platform/frameworks/base" path="frameworks/base" revision="ecb41a77411358d385e3fde5b4e98a5f3d9cfdd5"/> <project name="platform/packages/apps/Bluetooth" path="packages/apps/Bluetooth" revision="621bae79f1a250e443eb83d1f473c533bea493dc"/> <!-- sniff --> </manifest> 

Como puede ver, la única diferencia entre estos dos manifiestos es los valores de revisión de los repositorys git.

Respuesta corta:

Necesitas get manifest_static.xml de la construcción particular.

O bien, si solo le faltan algunos files de proyecto, entonces puede crear el file .repo en .repo git, agregar los git faltantes allí, y luego volver a repo sync desde la raíz de su repository. Más información sobre el uso de local_manifest.xml está aquí .

Me lo imaginé. Si tiene una label en un file de manifiesto (version.xml, por ejemplo). Puede reiniciar una label específica con el siguiente command:

 repo init -u <addres> -b refs/tags/<tagname> -m version.xml 

No tengo suficiente autoridad para enviar un comentario, pero solo quería aclarar la respuesta de Andrejs Cainikovs.

Repo acepta un SHA de commit-id además de una ref twig como argumento para la opción -b.

Como sugieren las respuestas, este argumento especifica la revisión del manifiesto que debe ser utilizada por el repository, no una revisión en ninguno de los proyectos a los que se refiere el manifiesto.