git - how to list all pull request with count of files changed

Question

I am looking for some command which tells me number of files committed in a single pull request. I would like to know count of files in a single pull request individual from beginning.

Question explained in real life scenario: Let's say for some myProject someone raised a pull request number 100 which has changes in 15 files.

I am looking for a command which list all pull request from 1 to 100 with count of changed files.

Please answer wrto Windows 7.

i.e.

• PR Number 100 has changes in 10 files
• PR Number 99 has changes in 5 files
• PR Number 98 has changes in 6 files
• PR Number 96 has changes in 22 files
• -
• -
• -
• -
• PR Number 50 has changes in 7 files
• .
• .
• .
• .
• PR Number 10 has changes in 2 files
• .
• .
• .
• .
• PR Number 1 has changes in 23 files

Answer 1

You can get a list of remote pull requests like this:

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

(assuming that origin is the name of your GitHub remote)

For a given commit, you can get a list of changed files like this:

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

You can put the above information together into a shell script:

    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

Which produces output on stdout like:

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

(there is also output on stderr, which you can take care of with standard shell i/o redirection).

This pretty much does what you want, with one major caveat: pull requests persist as refs in your remote GitHub repository even after they have been closed, so this will always iterate over every available pull request, past and present.

You could work around this by caching locally information about the highest PR number you've previously checked, and then skipping all PRs that are lower.