Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upRegression: listing repositories is unusable for any significant amount of repos #2143
Labels
Milestone
Comments
|
Azure DevOps tackles this problem by initially showing a list of repositories recently contributed to. There is a separate button to load the full list of repositories. This way the user can be prepared for a longer load if the repository they're after isn't on the recently contributed to list.
I think this is a pretty reasonable solution. It's simple and lets the user know what's going on. If streaming and caching GraphQL will take a while to develop, maybe we could do this as a interim solution? |
|
Here are some timings:
|
This was referenced Dec 20, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As much as I hate vague issue titles, it's pretty much that. Any user who has access to a significant number of repos (even if they only own a few, they might have org access with large numbers of repos) will have a bad time when listing repositories.
This is me loading the clone repo dialog from the 2017 start page. It takes two minutes to get anything to show up on the list:
There are two main problems here, which together make the UX poor:
A side effect of no caching and re-running the full query every time is that it might exhaust API rate limits and lock users out temporarily, depending on how much many api calls are happening. One of my attempts at loading the list resulted in a 403 forbidden: