IssueHuntAdd link to forked repo below the original #1129
cg-cnu posted onGitHub
To resolve this issue, jump to: https://github.com/sindresorhus/refined-github/issues/1129#issuecomment-371044209
Hey guys! Amazing addon with lot of awesome features 💯
Github displays the original repo path when visiting a fork. But, the original don't have link to your fork. Right now we have to access the forks from here...
My proposal is to add a forked to cg-cnu/refined-github below the original repo.
Let me know your comments and ideas. Will be happy to do a pr if you guys like it. Cheers 😄
There's already a PR at #1108
Thanks @salmanulfarzy for pointing that out. I Should have searched in prs before creating this issue. Closing this one.
Still a good idea to keep track of the idea outside the PR.
Thanks for reopening the issue @bfred-it , continuing the discussion from the pr #1108
Might be a crazy idea, how about just displaying the text fork : <user-name>/<repo-name> below every repo (apart from yours) irrespective of you have fork or not.
On clicking the link
- If you have fork, go to the link.
- if you don't have the fork, open the
Where should we fork this repository?modal dialog.
@sangeeth96, the best I can think of to get the link working with out making the api calls.
irrespective of you have fork or not
Too crazy. Not a fan of displaying links that are too likely to be 404s
Ok, here's what I suggest in detail.
<img width="151" alt="instant fork" src="https://user-images.githubusercontent.com/1402241/36660819-0d44a228-1b0c-11e8-8e8d-74320a95a35c.png">
- Change current "icon Fork" button to "▼"
- Add new link on the left with the text "icon Fork"
The new link would open the page /user/repo/fork + a query string, like:
https://github.com/sindresorhus/refined-github/fork?rgh-fork=trueThat page is exactly the content of the modal box, but we can load it without going through GitHub's AJAX.
- Detect the
?rgh-fork=truepage load in ourinitfunction - Hide the content via
hiddenattribute on<html>and abort the rest of RGH - When the page is loaded, click our fork (this will either just redirect to the fork or generate the fork)
Even if technically two pages are loaded, the user won't see the /fork page and it will feel like a simple redirect.
However, users without organizations don't have this modal at all, so they should be left untouched.
I'd suggest an alternative approach:
- Fork authors would open their fork at some point.
- When you visit a fork of your own (have upstream link in the header and settings tab).
- We could cache as a map that this upstream repo correspond to your fork.
- When you visit the upstream repo we'd check the cached map of your own forks and we'd add a link under the upstream name to your fork.
A caveat here is that you could have multiple forks you have access to of a single repo (forks in multiple organisations and user), but we can still support that by showing multiple forks in the header to choose from.
I think this is a simpler implementation and would show you the information that you've forked this in a familiar way.
The problem with caching forks:
- I fork Refined GitHub
- I send a PR
- I delete the fork and never visit it again
- Your link stays there forever?
I delete the fork and never visit it again Your link stays there forever?
I haven't thought of that indeed. Cache invalidation here is hard, but we can invalidate it on 2 events:
- Visiting the 404 URL of the fork (we could detect it's a 404 and the URL should be in our cache map). This would invalidate the cache after first click on the missing fork link.
- Detecting the deletion of the fork in the Settings tab and invalidating the cache for that fork. I don't think this would be too hard.
So the caching implementation is not so easier with the invalidation, but I still think it's a good one as we won't be performing API calls and you have the fork link on the page immediately in a familiar fashion. I don't think detecting the fork dialog or adding a drop down button would be a good experience.
We don't detect the dialog but we open an intermediary page invisible to the user.
There's no real dropdown, it's just the button that opens the regular dialog. If you don't like that "arrow down" we can leave it as is and just add an extra "your fork" button that either visits or creates "your fork"
Essentially the difference here is that in your case we might:
- not have the link of our fork if we created it on a different computer
- have a 404 link that disappears after the first visit (especially if deleted on a different computer)
and in my case:
- the link always visits the fork, whether it exists or not, that's why I wanted to hide it behind the regular "Fork" button.
It's exactly how the Fork button works when there are no organizations. Honestly I think GitHub should have handled it this way when it found organizations for the current user.
not have the link of our fork if we created it on a different computer
We should be using the synced cache across computers if you're logged in with the same Google account in Chrome or have the browser syncing configured properly on Firefox.
have a 404 link that disappears after the first visit (especially if deleted on a different computer)
If we invalidate on deletion and use synced cache, that won't be a problem.
that's why I wanted to hide it behind the regular "Fork" button
Regardless of implementation, I think showing the "forked from" link like in the mockups by @cg-cnu would be the best experience and most informative as soon as you visit the page.
Honestly I think GitHub should have handled it this way when it found organizations for the current user.
I've had legitimate reasons to have a fork both in an organisation and user account in the past. But yeah, GitHub should do that by default.
With storage.sync it could work 👍 , but we should probably still detect 404s just in case that fails to be uncached, since we don't have cache expiration yet #624
@cg-cnu Thanks a lot pal for opening up an issue! I was quite naive about this. @bfred-it really opened up my mind here and I see that he's still asking the right questions. I thought it'd be an easy addition and I was lazy and then my exams came in.
Detecting the deletion of the fork in the Settings tab and invalidating the cache for that fork. I don't think this would be too hard.
@hkdobrev Well, what if I'm deleting the fork from some other source where the extension is not present? That would mean the link would be present in the cache. Same goes for forking for the first time as well as for existing forks.
Even if technically two pages are loaded, the user won't see the /fork page and it will feel like a simple redirect.
@bfred-it So if I can understand this right, the original Fork button's function would now be to open up /fork where we put handlers to take care of a redirect. Two questions:
- What if I wanted to create a new fork? I use the dropdown?
- This maybe stretching it but what if I have forks under my account as well as orgs I manage? Then would I have to rely on the dropdown to do the switching to an org's fork?
TBH, my intention from the beginning was to go with forked to option below the title which feels like the appropriate place because forked to/from combined links are like a "toggle". But so far, that seems to cost more.
OK, if you think using the API is the way to go, I'm fine with it. It would help when another person did the fork in your organisation and you have access to it, but haven't opened yet which would be the great use case of that addition. We already had cases where 2 developers of our organisation needed to fork the same repo only to realise we already did that.
However, I'd love the link to the fork to be under the repo name as GitHub does it for the upstream to help with discoverability if you don't want to fork it or someone else in your org forked it.
What if I wanted to create a new fork? I use the dropdown?
Yes, just like now
This maybe stretching it but what if I have forks under my account as well as orgs I manage? Then would I have to rely on the dropdown to do the switching to an org's fork?
I initially thought that the Fork button should only point to the user, for ease, but I suppose it could just open whatever fork is already there.
- If there's no fork, create a user fork
- If there's just one fork, open it, whatever it is
- If there's more than one fork, open the user fork.
- If there's more than one fork and no user fork, show the
/forkpage as-is so the user can pick the fork.
OK, if you think using the API is the way to go, I'm fine with it. @hkdobrev
#1108 already uses the API and I'd rather not use it on all the repos I open, however it could make sense if we couple it with your suggestion and only poll the fork if we detected+cached it at some point.
@bfred-it 👍 on combining approaches for latest data + reducing API usage on repo visit.
I still don't think we need to do anything whatsoever with the Fork button visually or on click. I don't get the benefit really.
The real benefit is to know you already have access to a fork and you can navigate with a click in a very familiar way.
I agree with @hkdobrev. That was the main issue I intended to fix just like the guys here imagined this to be. This is kind of GitHub's own fault — for trying to add multiple functionalities to the same button under different state without trying to alter the appearance of the button to indicate the present state. But then again, I guess to try and fix all that is the spirit of this project.
I know we haven't really finalized on the implementation but since I'm at the moment kind of out of ideas, is there a way to show that forked to user/repo link below an upstream repo's page such that:
- No unnecessary API calls are made
- Not relying on authentication
- Works regardless of where you created/deleted forks
- No unnecessary side effects (such as creating a new fork) when doing this
- Link doesn't show up if the fork doesn't exist (i.e, no 404s)
When you visit your fork:
- Detect fork (e.g.
bfred-it/refined-github) - Cache it as
fork:sindresorhus/refined-github=bfred-it/refined-github
- Detect fork (e.g.
When you visit a non-forked repo:
If
fork:sindresorhus/refined-githubis in the cacheValidate the cache, i.e. fetch the fork (make sure this happens as little as possible). No API necessary, just a HEAD of
${location.origin}/${forkPath}If fork is still there, add a link to it next to the fork button, like in my mockup:
<img width="151" alt="instant fork" src="https://user-images.githubusercontent.com/1402241/36660819-0d44a228-1b0c-11e8-8e8d-74320a95a35c.png">
@issuehunt has funded $40.00 to this issue.
- Submit pull request via IssueHunt to receive this reward.
- Want to contribute? Chip in to this issue via IssueHunt.
- Checkout the IssueHunt Issue Explorer to see more funded issues.
- Need help from developers? Add your repository on IssueHunt to raise funds.
@sindresorhus has rewarded $36.00 to @jerone. See it on IssueHunt
- :moneybag: Total deposit: $40.00
- :tada: Repository reward(0%): $0.00
- :wrench: Service fee(10%): $4.00
Fund this Issue
Rewarded pull request
Click to copy link
Recent activities
