Cómo mostrar qué twigs se combinaron para dominar hoy

Sé que puedo hacer

git branch --merged 

para mostrar lo que se fusionó, pero simplemente genera todo. ¿Hay alguna manera de filtrar por date?

No y sí, dependiendo de lo que realmente pretendas preguntar.

Las tags de sucursales son cosas temporales, creadas y destruidas por capricho. Aquí hay un gráfico de confirmación en el que se creó una twig, se agregaron dos confirmaciones en un lado (la nueva twig), se agregó una confirmación en otro lado (la twig original), se fusionaron los dos lados y se agregó otra confirmación al final . En algún momento, se eliminó el nombre de la twig fusionada.

Marqué la fusión real con un asterisco * ; los nodos de confirmación restantes son simplemente o nodos ordinarios.

Tenga en count que aquí no hay tags de bifurcación adicionales, solo la línea principal.

 o--o--o---*--o <-- mainline \ / o--o 

Si pregunta qué twigs se fusionan con la mainline , solo la mainline sí lo está.

Ahora agreguemos otra label de twig, para que quede más claro cómo surgió la situación:

 $ git branch aux mainline~1^2 

El gráfico ahora es exactamente el mismo, pero hemos agregado una label de twig llamada aux :

 o--o--o---*--o <-- mainline \ / o--o <-- aux 

Si pregunta qué twigs se fusionan en la mainline , la respuesta ahora es la mainline y también la aux .

¿Cuándo se fusionó aux en la mainline ? No fue así : la twig se llamó zorg cuando se fusionó. Ese nombre se eliminó y se creó un nuevo nombre para que aux saliera de la git branch --merged .

Agreguemos una tercera label de twig, solo para ilustrar que puede ser aún peor:

 $ git branch newbranch mainline~3 

dando:

  ............<-- newbranch . o--o--o---*--o <-- mainline \ / o--o <-- aux 

Lo que puedes descubrir (no es del todo trivial, requiere un poco de trabajo de pies extravagante) es cuando se crearon los compromisos de fusión. En este caso, ese es el * commit. Es un descendiente del commit ahora labeldo como aux (y anteriormente zorg ), y en este caso particular es un padre inmediato (el segundo padre) de ese commit.

Tenga en count que esto ignorará las twigs que no están específicamente fusionadas en su twig, como newbranch . En este caso, newbranch es una twig que puede crecer (pero aún no ha crecido) a partir de una confirmación anterior a la punta de la mainline . ( git branch --merged mostrará, y es posible que desee o no contarlo).

Por supuesto, el nombre zorg se fue hace time (las tags de las sucursales son naturalmente temporales en git) y si alguien se cuela y elimina el nombre aux que acabamos de crear, así es ese. O bien, si alguien agrega una nueva confirmación en la twig aux ahora nombrada, obtenemos este nuevo gráfico:

 o--o--o---*--o <-- mainline \ / o--o--o <-- aux 

y ahora el * commit ya no es un descendiente directo del commit labeldo aux . Sin embargo, podemos determinar que * es un descendiente directo de un ancestro de la confirmación denominada aux . Pero no podemos (sin ayuda adicional) rebuild el hecho de que aux~1 solía llamarse zorg , y zorg se fusionaba con mainline , mientras que aux ya no se fusionaba con mainline .

Por lo tanto, la pregunta que debe responder por sí mismo es la cantidad de stock que se debe poner en los nombres de las tags de las sucursales, que se pueden crear y eliminar a voluntad; y si busca fusionar compromisos y compararlos con el compromiso al que apunta el nombre de la sucursal "count"; y luego pregunte si una de las dos dates en la confirmación es suficiente como su filter.

Hay dos dates, "autor" y "committer", junto con dos nombres de usuario y direcciones de correo electrónico. Es probable que desee la date de compromiso, aunque a menudo los dos son iguales, y para las fusiones, es particularmente raro tener dates diferentes. Además, tenga en count que es posible que necesite permitir zonas horarias (dependiendo de cómo realice su propia testing "¿es hoy?").


Cómo get la date de compromiso

Para cada twig b esa git branch --merged reivindicaciones fusionadas se fusionan en su twig objective (llamemos al objective t ) …

  1. Sabemos que el compromiso al que apunta el nombre b es un antepasado del compromiso al que apunta t . Usa git rev-parse para get los SHA-1 sin procesar para cada b .
  2. Usando git rev-list --merges t , podemos encontrar revisiones que son commits de fusión que son ancestros de t .
  3. Para cada SHA-1 extraído, observe todos sus ID de confirmación padre (puede hacer que git rev-list produzca junto con el commit; vea --parents ).
  4. Si un padre coincide con el ID de una de cualquiera de las twigs b , tiene la fusión-confirmación que fusionó la twig b en t . Así que verifique las dates en esa fusión de compromiso. En cualquier caso, elimine SHA-1 para b de su list de artículos necesarios para verificar la date.

Repite lo anterior hasta que se consumn todos los SHA-1 para todas las twigs b , o te quedas sin fusiones.