New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Be smarter about the repository list we download #2148

merged 6 commits into from Jan 7, 2019


None yet
2 participants
Copy link

jcansdale commented Dec 21, 2018

NOTE: Show repositories user has contributed to in Clone/Open dialog

This PR is intended as a low impact fix for the Open from GitHub dialog when the user belongs to an organization that owns 1000s of repositories.

What this PR does

  • Display at most 100 repositories per organization
  • Order the repositories by their most recent commit (freshest first)
  • Warn when an organization has hit the 100 repository limit
  • Show repositories that the user has contributed to


When displays a list of repositories for a user or organization, the repositories are ordered starting with the one with the most recent commit. This ensures that the freshest repositories, which are most likely to be of interest to the user appear at the top of the list.

A user might have worked on a repository that doesn't appear on their organization's list of 100 repositories with recent commits. To ensure that these repositories are also visible, the list of repositories that the user has contributed to has also been included in this list. This includes repositories they created, committed to, opened an issue on or sent a pull request to.

If a user wants to clone a repository that they don't own, isn't on the top 100 active list and they haven't contributed to, they always have the option to open it using the URL tab (like they would for a 3rd party public repository).

What to expect

  • The repository list should appear faster. Here are some before and after timings for a user that has github on their organization list (github and Microsoft both have well over 2000 repositories)


RepositorySelectViewModel ReadViewerRepositories took 39.86 seconds
RepositorySelectViewModel Read 2788 viewer repositories


RepositorySelectViewModel ReadViewerRepositories took 3.49 seconds
RepositorySelectViewModel Read 309 viewer repositories
  • Repositories will be displayed in order of when they were last commited to (the same as the<owner> view on



  • Added new Contributed to repositories list


  • If an organization has over 100 repositories, this will be indicated in the section heading


  • All of a users own repositories and repositories that they're collaborators on will appear (no 100 limit)


  • Is 100 most recently pushed too literal? Would 100 most recently updated be better?

Fixes #2143

jcansdale added some commits Dec 21, 2018

Show max 100 recently pushed repos for each org
Limit the number of repositories displayed for each org to the 100 most
recently pushed ones. This should stop organizations with 1000s of
repositories from having a disproportional impact on the load time.
Set both affiliations and ownerAffiliations
Explanation by @nicksnyder:

Before this change, the affiliations field was overloaded to mean both
the affiliations that the viewer had with the specified repositories,
as well as the affiliations between the user that the connection was
operating on. This caused a host of issues in various places, and we
opted to separate them out to allow for more flexibility.

In order to fix the above, the proper behavior would be to pass the
full list of arguments to both connections (affiliations and
ownerAffiliations), which should provide you all of the possible

@jcansdale jcansdale changed the title [wip] Be smarter about the repository list we download Be smarter about the repository list we download Dec 21, 2018

@jcansdale jcansdale requested review from shana and grokys Dec 21, 2018


grokys approved these changes Jan 3, 2019

Copy link

grokys left a comment

I think this makes sense. We could improve this by paging in more results and updating the UI dynamically, and by caching but i think this makes sense for now.

@jcansdale jcansdale merged commit 645db55 into master Jan 7, 2019

2 checks passed

continuous-integration/appveyor/branch AppVeyor build succeeded
continuous-integration/appveyor/pr AppVeyor build succeeded

@jcansdale jcansdale deleted the fixes/2143-show-100-recently-pushed branch Jan 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment