Identificar compromisos de fusión 'ascendentes', no desde dentro de una bifurcación

Estoy intentando identificar compromisos de fusión de request de extracción en el historial de git.

Normalmente podemos usar algo como:

git log --merges |grep 'Merge pull request'` 

Sin embargo, soy parte de un proyecto distribuido con varias bifurcaciones de repository, y he descubierto que las asignaciones de fusión de request de extracción que formaban parte de la stream de desarrollo de la bifurcación están contaminando esta salida. Esto incluso se observa en la UI de Github.

Ejemplo:

 18b389... Merge pull request #2222 from Fork/master <-- Fork/master to Upstream/master for feature X - Want. ea3e5b... Merge pull request #12 from Fork/feature-x <-- Fork/feature-x to Fork/master - Dont want. 

Me gustaría aislar solo las asignaciones de fusión entre horquillas y aguas arriba, no entre twigs de horquillas o horquillas de horquilla. es posible?

Mi objective real es poder identificar todos los SHA de compromiso de fusión de request de extracción entre un range de confirmaciones, pero estos compromisos errantes contaminan los resultados con references a RP no relacionados: no hay distinción entre fork y upstream en el post de confirmación.

Esto no es posible hacerlo al 100% de manera confiable. Pero aquí hay algunas maneras de acercarte:

  • ¿Puedes grep en alguna otra parte del post de compromiso?
  • ¿Puedes navegar por la list de requestes de extracción en la página de GitHub de Upstream?
  • Intenta agregar el conmutador --first-parent a tu llamada al git log . Puede que no le proporcione todas las requestes de extracción relevantes, pero no debería darle ninguna de las que no desea.

--first-parent le dice a git log que solo siga al primer padre de un commit de fusión, en lugar de seguir a todos los padres. La twig en la que se fusiona siempre es el primer padre, por lo que es una forma efectiva de ver solo la historia que sucedió directamente en la twig que está viendo.

Lamentablemente, hay una cosa que puede arruinar la historia del primer padre, es decir, la fusión que ocurre cuando alguien tira. Si la Persona A está trabajando directamente en el maestro, y algo más se envía al server mientras tanto, se producirá una fusión (a less que se configure de otra manera) cuando A tira. Y en este caso, las confirmaciones locales de A serán el primer padre, y lo que se empujó mientras tanto será el segundo padre, lo que significa que no se mostrará en el git log --first-parent .