The very first row to be appended to the table is not taken into account by the current sorting algorithm:

The algo that is found in 2 different places (the Chrome Extension, and the Website):

function getTdValue(rows, index, col) {
  return rows.item(index).getElementsByTagName('td').item(col).getAttribute("value");
}

/** 'sortColumn' index starts at 0.   https://stackoverflow.com/a/37814596/9768291 */
function sortTable(table_id, sortColumn){
  let tableData = document.getElementById(table_id).getElementsByTagName('tbody').item(0);
  let rows = tableData.getElementsByTagName('tr');
  for(let i = 0; i < rows.length - 1; i++) {
    for(let j = 0; j < rows.length - (i + 1); j++) {
      if(getTdValue(rows, j, sortColumn) < getTdValue(rows, j+1, sortColumn)) {
        tableData.insertBefore(rows.item(j+1), rows.item(j));
      }
    }
  }
}

Searching with commits helps when there's a huge number of repositories that have less commits , like 10 or 20 which are easily not the best option

There was an issue for this
isaacs/github#1206

I built a code pen for this https://codepen.io/wakaztahir/pen/YzRVzZz?editors=1000

It doesn't work properly at the moment since Github doesn't support this , It could work if a little effort could be put into it

I would also like to support maximum stars to limit displaying popular repositories that I've viewed thousand times , So repositories with many commits and less stars tend to be secret gems.

Potentially:

• When reaching 80% of the remaining Rate Limited calls
• Turn the "loading" button red and if clicked: abort

A proposed implementation was made there: #7 (comment)

It seems like all the used API endpoints only use public data and therefore shouldn't need any scopes.

While examining the list from:
https://useful-forks.github.io/?repo=CouchPotato%2FCouchPotatoServer

We see results like:

However visiting one of the forks:
https://github.com/julien78910/CouchPotatoServer

This repo is a fork of a fork, and it may be ahead of its upstream, but that fork itself is behind.

It could be interesting to provide a real-time counter of the amount of GitHub API calls:

• amount issued for the current query
• amount left on the current token
• approximated amount ?

The approximated amount would be displayed at some point before the query begins.

estimate = 1 + total_forks + (total_forks / 100) + (sub_forks_probability * total_forks)

A warning could be issued if that value exceeds the maximum amount of API calls that can be made within an hour with the current token.

Not sure if this is to be expected somehow, but I noticed nothing in the Issues about this: I'm getting lots of duplicate results displayed, the same lines with the same values. When exported to csv, it is the same.

For example, the file useful-forks-https\ __github.com_zyedidia_micro_.csv has 104 lines (including the header), while with duplicate lines removed, it only has 59.

I did run useful-forks on repo that has >5000 forks, and naturally got GitHub API rate-limits exceeded. It would be nice if there would be a way (button?) to resume scanning after waiting long enough to be no longer blocked on API calls. I tried editing access token to re-save it, but it did not resume activities.

Current stats:

• Empty cache and hard reload: 2.39s
• Refresh page (thus using cache): 1.52s

Currently making some tests using npm and webpack in the following branch: https://github.com/useful-forks/useful-forks.github.io/tree/npm+webpack

The current results look promising: they shave more or less a whole second on both stats.

The link for open source website in :

Thanks to star-history's open-source website which I adapted for this project

leads to a 404 Github page

Nice project :)

Sometimes, it takes a long time to get all results, but the output can't be easily exported.

It would be great if there was a way to cache the results since they take a long time to generate and require a lot of API calls.

The current code assumed master was the default branch, but repos created after the 1st of October 2020 now have their default branch named main. This results in all forks being filtered out and errors being logged in the Console.

Example: https://useful-forks.github.io/?repository=aotuai/brainframe-qt

Should be fixed by dynamically picking up the URL from the initial request (hopefully).

Example URL to test with: https://useful-forks.github.io/?repo=EsotericSoftware/kryonet

The spinner is removed from the button before the recursive exploration of the whole tree of repositories is completely explored and filtered.

This spinner is supposed to act as visual feedback to the user so that he may know when the whole process is done. It also prevents overriding the current work with some other search (simultaneous searches could cause problems).

I'm not sure people actually use this tool on their phone, but it would be nice to cover that edge-case. I think it could be solved by using <span> and flex-box.

This is rather low on the priority list, though.

As someone who's never used the GitHub API before, I'd like a link to https://github.com/settings/tokens in this popup message, so I can quickly find the well hidden page to make myself a token.

(I'll make a PR in the next few days, just writing this down).

When the 403 - Rate Limit Exceeded error happens, one of the headers is x-ratelimit-reset: 1614575718. The digit is a UNIX Timestamp which could be converted to display how long the user should wait before trying again.

When the date of a displayed fork is more recent then the one for the queried repository, highlight it (kind of like behind is green when the value is 0).

how about allow search only selected branches?
on that way we can filter out unwanted branches.

As far as I'm aware, that's a bug in the GitHub API itself. All we can do is wait.

I've created this thread on the GitHub Support Forum: https://github.community/t/bug-watchers-count-is-the-duplicate-of-stargazers-count/140865

Hello there! Thank you for a fantastic addition to Github!
It is making life so much easier than doing it with shell magic and parsing the DOM ...
With that being said:

I am mostly interested on the projects that have the most modifications. And I can imagine different people might want to try different things based on different criteria.

Exposing more of the sorting options would be a nice addition to this nifty tool!

https://docs.github.com/en/rest/repos/forks?apiVersion=2022-11-28#list-forks

This endpoint some times returns erroneous repos, and seems to also return private repos.

A few API calls could be avoided, with the added benefit of getting less pollution in the Console.

Maybe add the options in the Settings, in case someone somehow needs that?

Actually there are nothing difference between them and the parent repo. So it would be better if they can be ignored too.

The URL doesn't update with the queried repo, which makes bookmarking impossible.

Instead, it shows "(1 calls)" at the top-right and no forks are displayed.

If the user is prompted for a token, and it is given (saved), either:

• Resume scanning, or
• At least re-activate the scan button

The hover color for the Chrome plugin are not adapted to GitHub's Night-Mode.

Thanks

Some times you might accidently start your search from a fork and the algorithm will only look into its children, thus potentially leaving a good portion of the fork graph out of the exploration.

Having a way to get the user to be aware that they are not querying a repo which is the root of the tree could be a nice addition.

Additionally, providing a single-click solution that would allow them to search from the root (or the direct parent?) would be nice.

Example link: https://useful-forks.github.io/?repo=facebook/sapling

I realized that when I go to explore a repository, I don't really care about the repo's landing page (e.g. landing page: https://github.com/mayhemheroes/eden).

Taking the last fork listed as an example, maybe that link should open facebook/sapling@main...mayhemheroes:eden:main instead of https://github.com/mayhemheroes/eden

Or maybe the "ahead" and "behind" badges could be those links.

I'd love to hear some thoughts about this.

just added this to the top of the script and it worked on Violentmonkey firefox

// ==UserScript==
// @name        Useful Forks
// @namespace   https://github.com/useful-forks
// @match       *://github.com/*/network/members
// @grant       none
// @version     1.5
// @icon        https://useful-forks.github.io/assets/useful-forks-logo.png
// @author      Useful Forks
// @description Displays GitHub forks ordered by stars, and with additional information and automatic filters.
// @require     https://code.jquery.com/jquery-3.5.1.min.js

// ==/UserScript==
// put the script down here !!

title

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.

Would be nice to be able to sort by each column:

On results pages where the list of forks shows how many stars, forks, and watchers each one has (example), there is a lowercase letter x (x) where a multiplication sign (×) would serve better.

To reproduce:

1. Install and activate the Chrome Extension
2. Go to an Insights page (https://github.com/useful-forks/useful-forks.github.io/pulse)
3. Navigate to the Forks tab

Somehow that doesn't trigger the scan, but if you land on that Forks tab from elsewhere than the Insights page, it works.

This is a fork: https://github.com/anchan828/json-ast
And it has a few parents and siblings, but this page is empty: https://useful-forks.github.io/?repo=anchan828%2Fjson-ast

As title says

It would be useful to see when the last commit was made.

Even better would be to see the date of the last upstream commit as well, because "70 commits behind" say nothing about dates. But not sure how difficult it will be.

Great tool. Thanks! I finally don't have to scroll through the giant graph where I don't know what's what.

Quick suggestion, would be nice to add link back to the original project too. Perhaps add it at the top in the table?

Currently, this setting option only takes effect on the next query.

It should apply immediately.

I have hit this unfortunate message

It's also possible that the queried repository has so many forks that it's impossible to scan it completely without running out of API calls. :(

while scanning https://github.com/dbeaver/dbeaver.

I would gladly give up some Local Storage in order to be able to fully scan a repo.

I will just give my whole thought process, even though it might be complicated to do it in one go:

1. Keep API calls counter #7, number of API calls still available, and API limit refresh time
2. Store all inactive forks in a cache for a some time (e.g. 1 week).
   Add a tooltip on the side of the page "Skipping x number of forks because they are empty [reset cache]"
3. When the number of API calls still available is zero, start the API limit refresh timer as a countdown
4. Store the current results in cache, with their fetch timestamp (e.g. for 1 day)
5. Add/Enable a button [continue fetching] when the [API limit refresh time reaches zero | it is detected that there are API calls available]

and lastly,

I don't know how feasible it is (it doesn't look like it), but server-side caching shouldn't be too much (I don't think that table would be too much to store as JSON), and might help "fight" the scourge empty forks.

how about allow search only forks updated the last 1 day / 1 week / 1 month / 1 year / custom?