Second Order Forks commit diff should relate to Source repo

[skepticalwaves]

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.

[payne911]

Hi, thanks for opening the issue!

From what I understand, julien78910's parent repo (mozvip) being 3611 commits behind the queried repository (CouchPotatoe), you believe that julien78910's row shouldn't have a green behind=0 badge. Do you think those reported numbers should always relate to the queried repository?

As it is, the "problem" is actually a manifestation of a design decision. The tooltip when hovering the badge explains it:

I personally find it much more useful to know that a fork of a fork isn't behind its parent then to know how many commits it is behind the very source of the fork tree. However, I am very much open to discussing this.

One thing you might want to know as well, is that you do not need to begin the search from the source. For example, here is a scan starting from one of the more popular forks of that project (showing a few top results of https://useful-forks.github.io/?repo=mozvip/CouchPotatoServer):

As you can see, a Source button is provided so that you can expand the search further up the tree.

---

There are definitely many ways the whole User Experience could be improved. Feel free to share some ideas and make some suggestions. :)

[skepticalwaves]

Do you think those reported numbers should always relate to the queried repository?

Yes, that is what I expected.

I personally find it much more useful to know that a fork of a fork isn't behind its parent then to know how many commits it is behind the very source of the fork tree. However, I am very much open to discussing this.

From my perspective, if I put in a given repo, I expected the interface to represent the forks and commit differences from that repo. So if a repo listed is a second (or higher) order fork, it either shouldn't be included (easier), or the interface should indicate its a higher order fork, and somehow display the differences at every level.

[payne911]

Do you think those reported numbers should always relate to the queried repository?

Yes, that is what I expected.

Humm, maybe I could provide an option which allows one to switch between both modes, actually. I'll have to think about how I want to display that option.

But then deciding on which options would be the default behavior remains. I wonder what @fregante thinks.

So if a repo listed is a second (or higher) order fork, it either shouldn't be included (easier),

I firmly believe all the forks should be displayed, else users will be forced to potentially initiate tons of scans with the tool to find what they're looking for.

or the interface should indicate its a higher order fork, and somehow display the differences at every level.

Any suggestions on how to display this information?

I'm thinking a circled number at the very beginning of each row could display the fork's depth. Probably with a tooltip mentioning the name of the parent repo.

Maybe relationships could be displayed through arrows pointing to the parent (something like this?), or when a parent is hovered I could highlight the siblings. But that seems like a lot of work, so it'd be rather low on my priority list.

[skepticalwaves]

I'm not wedded to any particular way to display, the circles and arrows both sound reasonable, I'd just like it to be more clear what the relationship is for the ahead/behind in the case of higher order forks.

I'm 👍 for whatever change happens.

[payne911]

@skepticalwaves I just recalled why I felt like I was forced to use the number that relates to the direct parent.

Think about this scenario:

• an abandoned source repository
• a fork which is active
• someone forked the active fork, but never did anything with it

Now you either have that 2nd order fork as behind its parent, or at the same point in the commit history. Both of those possibilities are "false positives" because the fork would still appear in the "useful forks" list.

To display the actual number relative to the source repo, I believe I have only two options:

1. Use a heuristic which could be faulty (my recursive calls would pass down the sum of the commits diff of the parent with its parent)
2. Use twice as many API calls as I am already because I'd have to query the parent's diff anywhere to be able to discard those false positive accurately

I would gladly go crazy on the amount of API calls, but unfortunately GitHub is rather restrictive when it comes to the amount of calls permitted every hour: I thus have to be very thoughtful about each one of them.

I'm thinking the best way to accommodate your need would be to leave the default setting as it is, but to allow users to change to one of the 2 options presented above (that would probably result in a "3 radio-buttons" setting within #24).

[skepticalwaves]

I'm fine with the solutions presented, but I'd also like it to be made clear where the which results displayed are a higher order forks.

[payne911]

but I'd also like it to be made clear where the which results displayed are a higher order forks.

Yes, I will try to make a visual change to represent that. I'm still thinking about it, though.

[payne911]

A first step in the right direction. Not there yet, though.