Introduction

One problem with forking a GitHub project is that some people fork a project and decide to work on their own version, because:

• the features they want to add are misaligned with the vision of the original author, so they are forced to develop own version;
• the cost of following the rules of the original author (style, tests, documentation, publishing, etc.) is too big or too long for a quick change;
• the author is unavailable or doesn’t want to longer maintain the project.

Any of these three cases causes new developers to create and develop a project fork, maintained parallelly to the original project. If you come to a GitHub project and want to use the most recent or feature-rich version of the code, you’d have to review every fork to select the best one as the base for your fork. It is doable but still tedious when there are 10 forks. It is impossible when there are 900 forks.

I created a tool to greatly facilitate this task. (To be honest, it is a spin-off from a project started by techgaun…)

How to use

The following application allows to list all forked repositories and check which was the most recently updated or which contains more commits, to choose the most active one.

1. Paste the name of the repository: user/repo or full GitHub link.
2. Provide a personal GitHub token. It is used only to increase the limits to query the GitHub API. The token is stored in Local Storage only, not sent anywhere except for the GitHub API.
3. Expand Options to increase the maximum amount of forks to retrieve and to utilize some kind of caching.
4. Click Find.
5. In the table, you will see the list of all forks, including the original repository marked in bold.
6. Click on the box in the Diff column to see the list of commits.

Optimizations

Since this application retrieves commits from every fork, it is slow and uses your quota (it resets every hour, don’t worry). However, I added two options for caching the results:

• Same size – if a fork has the same size as a fork that has already been read, it is assumed to be the same and contain the same commits.
• Same Push Date – same but looks at the Last Push date. If both are selected, both conditions have to be satisfied at the same time. If the condition is satisfied, commits for the second fork are not retrieved but assumed to be the same as in the first fork.