You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
The text was updated successfully, but these errors were encountered: