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

Solution 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.

Solution 2

This works for bitbucket

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

Comments

[ankitd]

Thanks for the answer. I am using windows 7 am not sure how to run these things. or how to run shell script on windows 7.

[ankitd]

should I give origin as stash path to develop branch?

[larsks]

I can't assist you with the Windows question. I'm not sure I understand your second question; what do you mean by "stash path"? In this answer, origin is the name of a git remote (that is, the place from which you cloned the repository). It's not a branch name.

[ankitd]

If these thing cant be run on windows. Is there any way we can get these thing in "Source Tree"?

[larsks]

You can certainly run these on Windows; all you really need is the bash shell, a couple of standard utilities, and the git cli. But I haven't worked recently enough with Windows to provide any guidance on installing these things. Maybe a question on superuser.com would help.

[Samuel Lelièvre]

Running Bash on Windows 10 is supported, you need to activate the Windows Subsystem for Linux. To run Bash on Windows 7, install Git for Windows (which is really "Bash + Git" for Windows).

[Prasanna K Rao]

try this hub pr list -s all -f "%cD %pC%>(8)%i%Creset %t% l%n"

[Prasanna K Rao]

here hub is the CLI tool from Github. Could work with BitBucket too. Not sure though.

[Slava Abakumov]

This accepted answer doesn't handle these situations: removed files, files that were moved from one place to another, new files. And even not all changed files too. For example, I have pulled all the changes from the remote, ran that, and it reports for 1 particular PR: 1 file. I open that PR on GH and I see 153 changed files (changed, removed, renamed, new).

[larsks]

@SlavaAbakumov this answer is also almost five years old :). A modern solution would probably involve the gh command line client, although of course both now and when this answer was written a more flexible option would probably involve making use of the github REST api directly.

[Ted]

hub marked bitbucket support as wontfix github.com/github/hub/issues/140