For repositories with a short name like "codebase", I imagine users would prefer /diffusion/codebase/ over /diffusion/123/ as the canonical URI.

However, we can't easily do this because it conflicts with other existing URIs like /diffusion/new/, /diffusion/inline/, /diffusion/lint/, /diffusion/query/, etc.

I can either move all of the non-repository Diffusion services to some new URI or put canonical repository short names under a different base URI. I'm inclined to do the latter, and use /source/ as the base, so a repository with short name "codebase" would have canonical URI /source/codebase/. If you strongly object to this, you have, like, a couple of hours to complain, unless this turns out to be trickier than I think.

D15302 was the change I was most worried about here, and it seems to have been entirely straightforward. I now expect to move forward like this:

• Make callsigns optional.
• Do a large amount of adjacent work untangling all the "we want our repository to have 30 different URIs, some of which only work on Tuesdays" use cases (T10366, T7516, T5406, T4705). This may be several days of work.
• Add the new "Short Name"-based display URIs (/source/codebase/ instead of /diffusion/123/).

Callsigns have been optional for some time (roughly since D15305 in February 2016, although there were a trickle of bugs after that).

URIs as a whole have been generalized and made more flexible in connection with T10366. The documentation on callsigns has been updated in connection with T10748.

Remaining work here is to make /source/repository-short-name/ ("Short Name URIs") work to access a repository, as an addition to /diffusion/123/ ("ID URIs") and /diffusion/XYZ/ ("Callsign URIs"). Most of the groundwork for this is in place, but the benefit is a minor cosmetic one.

Today, short names can be used to identify repositories in a number of other contexts, like bin/repository workflows.

Shortname is already used for the shortname.git portion of the URI. Would it be out of the question to allow a separate path to be configured, perhaps also including nested directories?

The use case is mirroring something like an Android distribution, where the original source has repositories organised into a logical hierarchy, and is often using repo to fetch the full collection of repositories at once.

Currently to put repositories under Phabricator, I need to go through and edit the path of each individual repostory in the repo manifest, but if the path could be more flexible on the Phabricator side, I could just edit the default remote, and keep the relative paths below that the same.

How would we distinguish between source/android/browse/carafe/ being "browse branch carafe of repository android" vs "browse the home page of repository carafe located at path android/browse/" in such a scheme?

How difficult would this be for someone to implement / does upstream have an implementation timeline for this?

It's entirely possible I missed some things in supporting the 25,000 different URI forms we now support, but just file a new issue if you run into anything since this task is now 200 years old with seventy pages of unrelated disucssion.