T2298 seems like a more tightly scoped version of this task - basically adding a little select or something that lets you choose the sort order of the repositories by name or most recently committed to.

+1 for wanting this.

@avivey, can you describe your use case a bit? So far we have two (Facebook and @hach-que) and they're very different.

We're based mostly on github, so we have organizations (basically team) that own repos; this adds up to lots of small repos.

Diffusion view isn't (?) sorted, so looking for a repo there is annoying.

(sorted by title; just realized that)

Oh, I forgot this existed -- good find. T3935 overlaps in some ways.

One note is that the original task predates ApplicationSearch -- at the time, it wasn't possible to filter or reorder repositories at all. However, I suspect ApplicationSearch hasn't done much for the high-count installs.

◀ Merged tasks: T3935.

To summarize T3935, the path forward here looks like:

• Implement Project/Repository relationships, see if that solves the problem.
• If it's still an issue, look at refining things.

This isn't much of an issue any more. For me, I simply defined a search called "Important Repositories" with the callsigns I'm interested in. It might be nice to allow administrators to make their searches public (so for example I could set "Important Repositories" as the default for anyone opening Diffusion), but it's not critical at all. I'm generally of the opinion that having the dashboard public and showing recent activity will be of much more use than this task.

T4103 covers configuring default search views.

First of all, a bit on our use case: We have a great number of repositories (central project alone consists of >40 modules (which will increase); add tools and lib-forks to that).

Being able to group repositories into projects already helped a lot. However, after doing so additional functionality was missing to effectively work with it:

• Set up search queries for everyone (like the built-in queries) in order to display projects repositories
• Repository listing in the projects detail page

For reference, I found the built-in queries logic to be in PhabricatorRepositorySearchEngine.php, functions getBuiltinQueryNames and buildSavedQueryFromBuiltin.

In the end, we grouped the repositories into projects, hacked built-in queries for diffusion per project, and extended the project page to list repositories.

We created several Phabricator projects for our one project. One for the main components spanning multiple repositories (for unique component versions), one for secondary components like library forks and project specific tools, one for tools like our Phabricator fork, one for proof of concept specific repositories, one for a specific type of components, (one for obsolete repositories).

For our current use case this works. However, I can see how managing more than one product would introduce the need for another level of categorization. If we would want to mangage our previous major product version with Phabricator as well we would have yet more projects, and we would not have a grouping of projects belonging to one or the other major version.

In T3102#18, @epriestley wrote:

• Implement Project/Repository relationships

See https://git.wikimedia.org/projects for an example (in gitblit) of what's needed. (Can this be added to Wikimedia tasks here?)