search

useful-forks / useful-forks.github.io

Improving GitHub's Forks list discoverability through automatic filtering. The project offers an online tool and a Chrome extension.
https://useful-forks.github.io/
MIT License
1.18k stars 61 forks source link

Keep forks with commits to non-default branches #33

Open katrinleinweber opened 3 years ago

katrinleinweber commented 3 years ago

1k thanks for this tool :-)

Relevant work on a fork can be hidden in a non-default branch, if for example the author planned to submit a PR properly, but eventually didn't.

Would it be useful here to also check for such branches (not just the default branch), and keep forks in the results list, if any are found?

I've implemented such logic a while ago in a similar tool. While I can't port it to JS, I hope the example is still helpful to consider this idea.

The increased number of API calls can be mitigated, if necessary.

payne911 commented 3 years ago

1k thanks for this tool :-)

My pleasure! It was born out of personal necessity and curiosity. :)

Would it be useful here to also check for such branches

Absolutely ! Early on, I had considered it and thought it wasn't worth the API calls. But now things have changed.

The increased number of API calls [...]

That is indeed my main concern. For massively forked repositories, I'd rather see more results with a simplified view, than an incomplete but detailed list. And I assume this tool's relevance increases with the amount of forks, so I'm mostly aiming at keeping it this way.

My current plan is to allow people to save their "search preferences" through the little gear icon next to the search input text field, so that would be how I would add the feature of scanning all branches.

The simple act of querying for the list of branches of a fork is an API call. Then comparing branches would be another one. That's pretty much doubling the amount of calls the tool is currently making, hence why I'd keep it as opt-in option.

[...] can be mitigated, if necessary.

Is your proposal to require user input on each processed element before continuing? I personally do not think that is a very applicable thing for this tool.

katrinleinweber commented 3 years ago

Yeah, that approach is for a slightly different goal than useful-forks': Assuming that each finding needs to be reviewed manually anyway, so waiting for the full list isn't needed.

… save their "search preferences" …

Also cool, thanks! :-)