I feel that in a multi-repo environment, project PTags and Description are very important, and in a very-small-number of repos it will probably be empty, so I'd vote "Show them above the fold".

Some purely technical stuff:

• Many real repositories have tens of thousands of branches, so putting them all in a plain <select /> won't work well on its own. A common reason for this is that users treat git push like "Save Changes", and the remote has thousands of epriestley-tmp-fix-T123-tmp-bakcup sorts of branches. GitHub solves this with a searchable JS widget sort of thing.
• Unlike GitHub repositories, repositories in Phabricator may have an arbitrarily large number of clone URIs with the same protocol, so the "https" dropdown might contain options like "https, https, https, https" which can not easily be distingiushed. For example, an open source project may list several mirrors on different services (GitHub, BitBucket). This arose from a cluster of use cases in T10366 including listing mirrors and customizing individual display URIs.
• On GitHub, all remote URIs are read/write, but in Phabricator some may be read-only.
• Subversion has no branches or tags, although those elements could just be removed from SVN repositories.
• If the horizontal tabs fold into a hamburger menu on mobile like the side nav does, they may require a substantial amount of JS too.

On GitHub, all remote URIs are read/write, but in Phabricator some may be read-only.

Specifically, I mean that the dropdown as shown might show "https, https, https, https, https", and you might have to select each one in order to figure out if it was read-only or not. This is rare (most repositories do not have multiple clone URIs for the same protocol) and I believe we make some effort to sort read/write URIs to the top, but it could be frustrating to feel like you had to fish around blindly.

As a general direction thing, I expect T5000 to reduce the "branch dependentness" of the world, not increase it. The general idea is to, to the greatest degree possible, let you use git push but not create a permanent branch in the remote as a side effect. I want to provide tooling that fights against "git push = save changes", not embrace it, even if that means extreme solutions like T10691 where we create a totally separate "fork" repository for all your personal branches just to keep them out of the main remote.

A common reason for this is that users treat git push like "Save Changes", and the remote has thousands of epriestley-tmp-fix-T123-tmp-bakcup sorts of branches.

It seems like Differential Revisions help resolve a lot of that too. The two differences I can think of are longevity and collaboration. When we have long-running branches we clone and manage separately (though this seems to be the preferred Mercurial branching strategy over hg branch, or at least was for a good while). Then painfully merge everything back after months of changes :c

I got an email about the last update but the contents look like some of the content is not HTMLized properly

Should I file a bug?

See T12814.

Gah I searched "mockup email" not Pholio..

@epriestley I think "Clone" via a button -> dialog is like 20 minutes of work for me, and the dropdown 2-3 days of fighting javascript. Unsure which you prefer in the long run.

Gonna try the button and see if it sucks.