Question: Check what files are touched by Pull Requests

[remyleone]

Hello,

I would like to know if there is somebody working on this feature:

• Usecase: You want to submit a PR on a lot of files but you don't want all people to rebase massively so you would like to target your work on files that not a lot of PR touch (for example stylistic changes)
• Implementation: Sync in local all the PR open that are touching each files
• API:
  hub pull_requests my_file
  Modifed by #xxx (github.com/.../)
  Modifed by #yyy (github.com/.../)

Do you think it's possible? Do you think of a better API? Is there something else that provides similar features?

[mislav]

I think that would be a useful feature. I even have a local command to look that up for me, but it works on branches in the repo, and not on PRs.

I'm not sure if it would be a good idea to build this into hub, however. The complexity of making and maintaing this command would be large, and its functionality is very specific.

What about repos with a large amount of PRs that may come from forks, like a popular open source project? This command would be slow if it needed to fetch each one of those.

[remyleone]

For the PR, they could be cached with a function like sync. An upstream
repo can have a lot of PR but this sync doesn't need to be run each time.
It's more like an indicator of the files that are not too requested and the
PR pace for them isn't likely to change much. I understand it add
complexity, but I think the usecase is I think relevant enough.

Do you think this kind of feature could take place in an other tool?

2015-11-09 16:28 GMT+01:00 Mislav Marohnić notifications@github.com:

I think that would be a useful feature. I even have a local command to
look that up for me
https://github.com/mislav/dotfiles/blob/755ebe6fa8a9ec066f50f3f55bb6eb96aad13462/bin/git-branches-that-touch,
but it works on branches in the repo, and not on PRs.

I'm not sure if it would be a good idea to build this into hub, however.
The complexity of making and maintaing this command would be large, and its
functionality is very specific.

What about repos with a large amount of PRs that may come from forks, like
a popular open source project? This command would be slow if it needed to
fetch each one of those.

—
Reply to this email directly or view it on GitHub
#1026 (comment).

[mislav]

My goal for the next larger release of hub is to offer commands to expose lower-level API data (such as issues and pull requests) to scripts. Then, it would be trivial for you to have an external script in your environment that would consume data through hub and perform this kind of analysis.

[remyleone]

Perfect :) give me a heads up when it's available

Le lun. 9 nov. 2015 20:37, Mislav Marohnić notifications@github.com a
écrit :

My goal for the next larger release of hub is to offer commands to expose
lower-level API data (such as issues and pull requests) to scripts. Then,
it would be trivial for you to have an external script in your environment
that would consume data through hub and perform this kind of analysis.

—
Reply to this email directly or view it on GitHub
#1026 (comment).

[mislav]

@sieben It only took a few years 😉

Now that there is a new hub api command, I will close this feature request and leave implementing this as an exercise to the reader. https://github.com/github/hub/releases/tag/v2.8.3 #2016

Thank you for suggesting!

[remyleone]

@mislav Do you know when the PullRequestChangedFile will come out from preview and be available in the explorer. I don't see how I can see what files are touched by a PR without this type. Alors is there a way to add plugins/aliases to hub so that we can distribute this feature to a large crowd?

[mislav]

@sieben I can't make predictions about when a certain API will be public. It's possible to also fetch it using the REST API:

hub api -H 'accept: application/vnd.github.v3.diff' repos/OWNER/REPO/pulls/PR | \
  grep '^diff ' -A3 | grep '^\(---\|+++\)' | cut -d/ -f2- | sort -u

Via GraphQL preview:

hub api -t -H 'accept: application/vnd.github.ocelot-preview+json' graphql -Fpr=PR -f query='
  query($pr: Int!, $per_page: Int = 100, $after: String) {
    repository(owner: "{owner}", name: "{repo}") {
      pullRequest(number: $pr) {
        files(first: $per_page, after: $after) {
          edges {
            node {
              path
            }
          }
          pageInfo {
            endCursor
            hasNextPage
          }
        }
      }
    }
  }
'

[remyleone]

Thank you very much. I've found a similar request. Do you think this is a feature that hub could provide native support for? It looks like a very interesting one especially in documentation/translation/localization work.

[mislav]

@sieben No doubt this feature could be immensely useful! But I don't have good ideas yet about how to expose this functionality properly in core hub. Until this clarifies, accessing this information via hub api would be the way to go for your scripts.