Git: si A se fusiona de B, y B se fusiona independientemente de A sin conflictos, ¿se les puede hacer el mismo compromiso?

En algún context, estoy trabajando en un progtwig distribuido que necesita hacer la administración de versiones y resolución de conflictos en time real con múltiples queueboradores, y estoy considerando usar Git (específicamente https://github.com/creationix/js- git ) debajo del capó. Cada usuario tendrá su propia reference, pero habrá una historia global (muy similar a lo que hace GitHub). Pero a diferencia de GitHub, todas las bifurcaciones de los usuarios deben ser iguales, y las requestes de extracción no son unidireccionales en una bifurcación en sentido ascendente.

Estoy considerando un escenario donde dos usuarios, que acaban de hacer sus propios cambios fuera de línea [confirmaciones mostradas a continuación como A y B] , eligen cada extracción de la twig de desarrollo de su queueborador al mismo time. Suponiendo que la fusión se realiza con la misma versión de Git, y no se encuentra nada remotamente parecido a un conflicto, las dos fusiones terminarían con el mismo tree, pero (hasta donde yo sé) ya que los usuarios que realizan las asignaciones de fusión tienen diferentes nombres, la fusión se compromete C y C 'tendrían diferentes hashes (y por lo tanto, serían diferentes).

...A---C / \ / O / \ / \ ...B---C' 

El caso es que, si no hay conflictos y los treees y los padres en C y C 'son idénticos, me gustaría hacer que parezcan ser el mismo compromiso, si acaso solo para permitir avanzar más rápido en el futuro. , y para permitir una presentación más limpia de commit-graph.

De la forma en que lo veo, si los nombres, correos electrónicos y times de confirmación se configuran automáticamente para ser idénticos en las asignaciones de fusión (es decir, fusionados por automerge@example.com a la última hora de confirmación de los padres), entonces C y C ' ser idéntico? Entonces, ¿sería equivalente a haber sacado C / C 'de una fuente ascendente autorizada? ¿Hay alguna trampa o peligro con este enfoque que deba conocer? ¿O puede Git manejar esto automáticamente con alguna funcionalidad desconocida para mí?

El order de los padres de C y C 'está invertido. El primer padre de C es A y el segundo padre es B (fusiona commit B en la twig que tiene commit A). Para C 'es al revés (fusionaste el compromiso A en la twig que tiene el compromiso B).

Git guarda los hashes de las confirmaciones principales en el object de confirmación. El primer hash que aparece es la confirmación a la que apunta la twig en la que se encuentra actualmente. Después de eso sigue el hash de los commits en los que te estás fusionando.

El order importa al calcular el sha hash. Dado que sha es bastante sensible sobre este tipo de cambios, las posibilidades de que los dos hash sean iguales son prácticamente nulas. Incluso si logras mantener todo lo demás igual. El hecho de que los commits estén en dos twigs diferentes es suficiente para deshacerse de los sha hashes.

ejecuta git cat-file -p branch-a y git cat-file -p branch-b para ver la diferencia. Habrá dos líneas con parent <sha1> allí y el order se invertirá.