cómo enumerar todas las requestes de extracción con el recuento de files modificados

Estoy buscando algún command que me diga la cantidad de files comprometidos en una sola request de extracción. Me gustaría saber el recuento de files en un único pedido de extracción desde el principio.

Pregunta explicada en el escenario de la vida real: digamos que para algunos myProject alguien planteó un pedido de extracción número 100 que tiene cambios en 15 files.

Estoy buscando un command que enumere todas las requestes de extracción de 1 a 100 con el recuento de files modificados.

Por favor, responde wrto a Windows 7.

es decir

  • PR Number 100 tiene cambios en 10 files
  • PR Number 99 tiene cambios en 5 files
  • PR Number 98 tiene cambios en 6 files
  • PR Number 96 tiene cambios en 22 files
  • PR Number 50 tiene cambios en 7 files
  • .
  • .
  • .
  • .
  • PR Number 10 tiene cambios en 2 files
  • .
  • .
  • .
  • .
  • PR Number 1 tiene cambios en 23 files

Puede get una list de requestes de extracción remotas como esta:

 git ls-remote origin 'pull/*/head' 

(suponiendo que el origin es el nombre de su control remoto GitHub)

Para una confirmación determinada, puede get una list de files modificados como este:

 git show --pretty=format:'' --name-only <ref> 

Puede juntar la información anterior en un script de shell:

 git ls-remote origin 'pull/*/head' | awk '{print $2}' | while read ref; do pr=$(echo $ref | cut -d/ -f3) git fetch origin $ref > /dev/null files_changed=$(git show --pretty=format:'' --name-only FETCH_HEAD|wc -l) echo "PR number $pr has changes in $files_changed files" done 

Que produce salida en stdout como:

 PR number 1 has changes in 4 files PR number 10 has changes in 1 files PR number 11 has changes in 4 files PR number 12 has changes in 7 files PR number 13 has changes in 5 files 

(También hay salida en stderr, que puede solucionar con la networkingirección estándar de E / S de shell).

Esto prácticamente hace lo que quiere, con una advertencia importante: las requestes de extracción persisten como references en su repository remoto de GitHub incluso después de que se hayan cerrado, por lo que esto siempre se repetirá sobre cada request de extracción disponible, pasada y presente.

Podría solucionar esto almacenando en la memory caching localmente información sobre el número de RP más alto que ha comprobado previamente, y omitiendo todas las relaciones públicas que son más bajas.