Fusionar desde la twig ascendente a la twig del proveedor, donde la sucursal del proveedor contiene un subset de las confirmaciones ascendentes

Estoy trabajando con un proveedor que proporciona un parche al kernel de Linux para soportar Android en la parte superior de su plataforma. Esto significa que basan su cadena de parches en una versión específica de Linux, y en su cadena de parches se incluyen algunos de los parches de Android (recogidos con cuidado, supongo), que se aplican a la misma versión de Linux.

Entonces la historia se ve así cuando se importa a git junto con nuestros cambios que se aplican en la parte superior:

v2.6.xy v_rel_x.y o_rel_z l--l--l---------v--v--a--v--a--a--v--v--v--------o--o--o 

Donde l son commits de Linux, v commits de proveedores, commits de android y o son nuestros commits.

Lo que hace que esto sea complicado es que el origen del kernel de Android git basado en la misma versión del kernel de Linux está completamente separado, con el siguiente aspecto:

  v2.6.xy v2.6.x.y+1 l--l--l---------l---l \ \ android-2.6.x \ a--a--a--a--a \ \ v_rel_x.y o_rel_z v--v--a--v--a--a--v--v--v--------o--o--o 

Ahora, quiero include todos los parches de Android en la versión de android-2.6.x, sin embargo, también quiero que todos los parches de los proveedores sean compatibles con su plataforma. Lamentablemente, bastantes de los cambios en el v2.6.x.y+1..android-2.6.x cambios v2.6.x.y+1..android-2.6.x ya se aplican a la twig v_rel_x.y . Por lo tanto, una fusión simple de android-2.6.x a o_rel_z crea una gran cantidad de conflictos, que son simplemente imposibles de resolver a mano.

¿Tiene alguna idea sobre cómo realizar la fusión de android-2.6.x a o_rel_z de manera confiable?

Y sí, hay realmente una gran cantidad de commits en cada twig, y ​​los parches de Android en el v_rel_x.y están completamente ennetworkingados con los parches del proveedor.

Mis dos centavos:

  1. El motivo del conflicto no es que tengas algunos de los commits seleccionados, sino porque algunas de las confirmaciones están cambiando los mismos files en los mismos lugares y git no puede aplicar el diff limpiamente.
  2. En caso de cambios conflictivos, no tiene muchas opciones: a) fusiona y resuelve conflictos para llevar el código al estado deseable b) intenta resolver conflictos automáticamente fusionándose mediante estrategias de fusión como –ours o – el suyo dependiendo de lo que considere más correcto para sus propósitos.

Mira aquí la documentation de Git merge

Otro enfoque que puede intentar es volver a establecer una base de su twig 0_rel_z sobre el upstream actualizado android-2.6.x

Finalmente, tu problema no son los conflictos en sí mismos, sino la cantidad de ellos con los que tienes que lidiar a la vez. Así que me gustaría mejorar el process de gestión de las actualizaciones, hacer esto más a menudo (por ejemplo, todos los días a la semana) y reajustar constantemente las twigs de desarrollo además de actualizar hasta que esté listo para finalizar el desarrollo de una característica.

¡Espero que ayude!