¿Puedo aplastar _otras personas_ commit de git en un RP enviado?

He recibido un RP y deseo aplastar los commits, así que es bueno.

No estoy seguro si puedo hacerlo o los respectivos autores tienen que hacerlo? Por supuesto, deseo mantener el nombre del autor haciendo reference a su compromiso squash.

NOTA: esta pregunta no se trata de que aplastara mis propios compromisos .

Así es como se ve el PR en Git:

enter image description here

o a través del cli:

c:\Projects\Foo>git log --pretty=oneline 7fab9ae1031c13414909668f342582bdc8081f5a <Author - Red> a02270b2014fd3995456773cd7badc7df0c72cf6 <Author - Blue> 6ae3d6c8b5a8b037c0e4dc88d24ec5598ff1933e <Author - Blue> 100f6513aacbe431b56f3082597749cddca284c8 <Author - Blue> d263a5c8924053678f455b5ee8515bbb16aacf49 <Author - Blue> c3cc5dbc13ac77e0a552a2d3132d255df3c7a6e4 <Author - Blue> 71f89b3f3dd583cd97d4a0806a973a4d1af64fe9 <Author - Red> f14ef616a852f3a7311f4f7b9e05d460e0574422 <Author - Red> 015f30b3828828404b5549ee8a7df2aefdfa9424 <Author - Red> 9b22a4d2ded54cb754883d9d6418a39eb34df7cf <Author - Red> 33a10e9828d04cf82439a6c60b8cf4c0c2f122a3 <Author - Red> 4615c7747c4546809b29e063986c697c7c64cbc4 Added Specific naming rules, section. b8ee154e38338022649caef40945c6f0297a59ce Added method parameters, section. bc860c7609cc80caf41fc5944c1b39201019a80e Added Input and View Models, section. ad6b3e4bee1cb9d8afcf9cd1fa8815769d80133b Fixed bad markdown formatting. 5929d5b38aad8bb7cc3da4976dd81883eab0f999 Added more testing info. 18b64dfc3769766ac2bb841e6346b555d00751f1 Create README.md d7761e57a5bbd7de587b766c83d2a3134c0bc58b Added xUnit and Shouldly NuGet packages. 7f2ea8cdd97958d347df8079ef2eebb6b7f1647c We need unit tests.... ee31bbfe0572e0e49872edcf1a6fc2c426ed0d15 :money_with_wings: We are alive! 

los compromisos que tienen los posts allí, esos son míos y no son parte de este RP.

¿Hay algo que pueda hacer? ¿O necesito que lo haga el otro autor?

Los comentarios terminaron convirtiéndose en una respuesta, así que los resumiré aquí:

No estoy seguro si puedo hacerlo o los respectivos autores tienen que hacerlo? Por supuesto, deseo mantener el nombre del autor haciendo reference a su compromiso squash.

Si eliminas cualquier commit, solo terminarás con un commit, y un commit solo puede tener un autor. Es posible que sigan apareciendo en el post de confirmación (Git lo hace de forma pnetworkingeterminada), pero perderá individualidad en el autor de la confirmación literal.

Entonces, ¿no puedo aplastar los commit azules (en uno) y luego los rojos commits (en uno)? entonces hay dos en el PR?

Sí, podrías hacer eso totalmente, y el aplastamiento debería ser algo que sugieras en las requestes de extracción para que solo transfieras una confirmación para cada una. Si comprimes todos los commits azules en uno y todos los commits rojos en uno logras lo que creo que quieres, que es limpiar tu logging de git mientras aún mantienes el historial del autor.

¡Estupendo! … alguna sugerencia de cómo se puede hacer esto?

Por supuesto. Puede volver a establecer la base de forma interactiva para aplastar múltiples compromisos juntos. Tus problemas vendrán cuando tengas una confirmación de color rojo en cada lado de las confirmaciones azules, lo que limita tu habilidad de squash.

Para los commits azules puedes aplastarlos en el primer commit de la list cuando git rebase -i HEAD~11 un git rebase -i HEAD~11 (que se carga en los últimos 11 commits para el rebasing interactivo).

Me burlé de algunos commits ficticios para usar como ejemplo:

 $ git log --oneline 7e8be9c Red b740f97 Blue 325b375 Blue 553d733 Red bb5599b Red 

En su console, elija "p" o "pick" para la primera confirmación azul en la list (bd63d63) y para todos los demás, dele "f" o "fixup" para descartar sus posts de confirmación, o "s" o " squash "si quieres conservar los posts de confirmación para ellos:

 $ git rebase -i HEAD~5 pick bb5599b Red pick 553d733 Red pick 325b375 Blue fixup b740f97 Blue pick 7e8be9c Red 

Cuando finalice la rebase, sus confirmaciones azules se aplastarán juntas:

 $ git log --oneline a341d97 Red 488c19e Blue 553d733 Red bb5599b Red 

Aquí es donde puede complicarse dependiendo de si Rojo y Azul han tocado los mismos files o no.

Si no lo han hecho, la mejor opción es seleccionar el Compromiso azul en una twig separada (sin Rojo ni Azul) o volver a basarlo, cambiar la base del original y aplastar los Compromisos rojos mientras se descarta el Compromiso azul, luego fusionar el twig temporal de nuevo en, por ejemplo:

 $ git checkout -b tempbranch $ git reset --hard XXXXXXX # this is the commit BEFORE any networking or blues $ git cherry-pick 488c19e 

El logging de Git ahora te dirá que tienes el compromiso azul aplastado.

Vuelve a tu twig principal y vuelve a establecer la base, esta vez omitiendo el Compromiso azul y aplastando los rojos:

 $ git rebase -i HEAD~4 pick bb5599b Red fixup 553d733 Red drop 488c19e Blue fixup a341d97 Red 

El logging de Git ahora le mostrará que solo tiene una única confirmación en rojo. Ahora vuelves cherry-pick el Azul una vez más:

 $ git cherry-pick 488c19e $ git log --oneline fc96b04 Blue 0280ef9 Red 

Entrarás en problemas si esos commits tocan todos los mismos files. En este caso, puede que necesite mantener la separación de Rojo alnetworkingedor de Azul.

Importante

Sugeriría encarecidamente que aconsejes a todos los queueboradores de tu proyecto de Github que networkinguzcan todos sus compromisos a uno solo como parte del process de request de extracción, entonces no tendrás que lidiar con estos problemas tú mismo.

HTH.