When viewing a file in master for instance, History can show what commits/PRs/tags where applied to it; acting as a lens to the _past_ of the file.
But it does not show the potential _future_ of this file:
cc https://github.com/isaacs/github/issues/556
IssueHunt Summary
list-prs-for-file featureIssueHunt has been backed by the following sponsors. Become a sponsor
I wish it was possible, but I don't think there's an API for that.
This would be super useful, but I don't think it's possible. Keeping this open though, as I would like to be proven wrong!
For anyone that wants this, please also send this feature request to GitHub: [email protected]
I made a Chrome extension, called Potential changes, as a proof of concept for this feature. Right now it's pretty limited and rough but I'm quite happy with the result :)
I've also open sourced the code for anyone interested.
{
repository(owner: "sindresorhus", name: "refined-github") {
pullRequests(first: 100, states: OPEN) {
nodes {
files(first: 100) {
nodes {
path
}
}
}
}
}
}
JSON output
{
"data": {
"repository": {
"pullRequests": {
"nodes": [
{
"files": {
"nodes": [
{
"path": "readme.md"
},
{
"path": "source/content.js"
},
{
"path": "source/features/add-closed-milestone-due-date.js"
},
{
"path": "source/libs/graph.js"
},
{
"path": "source/libs/icons.js"
},
{
"path": "source/libs/page-detect.js"
}
]
}
},
{
"files": {
"nodes": [
{
"path": "source/content.js"
},
{
"path": "source/features/add-star-repo-hotkey.js"
}
]
}
},
{
"files": {
"nodes": [
{
"path": "source/content.css"
},
{
"path": "source/features/add-diff-view-without-whitespace-option.js"
},
{
"path": "source/features/add-profile-hotkey.js"
},
{
"path": "source/features/add-releases-tab.js"
},
{
"path": "source/features/add-trending-menu-item.js"
},
{
"path": "source/features/improve-shortcut-help.js"
}
]
}
},
{
"files": {
"nodes": [
{
"path": "source/content.js"
},
{
"path": "source/features/add-pr-branches.js"
},
{
"path": "source/libs/page-detect.js"
},
{
"path": "test/page-detect.js"
}
]
}
},
{
"files": {
"nodes": [
{
"path": "source/features/fix-squash-and-merge-title.js"
}
]
}
},
{
"files": {
"nodes": [
{
"path": "source/content.js"
},
{
"path": "source/features/extend-file-types-filter.js"
}
]
}
},
{
"files": {
"nodes": [
{
"path": "source/features/mark-unread.js"
}
]
}
}
]
}
}
}
}
You can use the API v4 to get 100 PRs 脳 100 files at once, but for now it's in preview/beta mode, you need a custom header:
Accept: application/vnd.github.ocelot-preview+json
@bfred-it That query looks awesome! It will greatly simplify things compared to what I'm doing now. Essentially, replacing multiple requests with just one. Nice :)
I'm aware of v4 of the API but haven't explored it more because, besides the custom header, it also requires an OAuth token. I will definitely try this option in the future.
@issuehunt has funded $60.00 to this issue.
Version 4 of the API is now used often here, so I feel this can be implemented. But before I start working on this (would like to), how should this be implemented?
Here a few possible solutions:
One call when opening the repo (or blob page) for the first time. Cache the data for a limited time. When an blob page is opened, the cached data will be checked for usage.
The query is only called when the user manually requests it. E.g. by clicking an button (just like above mentioned "Potential changes") on an blob page.
Any better suggestions...
The assumption is that this should at least be implemented on blob pages. But also on edit pages? Or on the tree?
How would we visually show that a file is being used in an PR? Maybe the same way as we do with issues linked in PR (e.g. https://github.com/sindresorhus/refined-github/issues/1197 Closed in #2102 label).
Should we actually cache the data?
Query (small change):
{
repository(owner: "sindresorhus", name: "refined-github") {
pullRequests(first: 100, states: OPEN) {
nodes {
permalink
files(first: 100) {
nodes {
path
}
}
}
}
}
}
Let's first discuss where this should be implemented?:
My preference are going to blob & edit pages.
Solution 1 sounds good: trigger call when on blob/edit pages
1- or 2-day caching is ok I think.
I want to give this a try.
@sindresorhus has rewarded $54.00 to @jerone. See it on IssueHunt
Most helpful comment
@issuehunt has funded $60.00 to this issue.