Page MenuHomePhabricator

Diffusion - June 2017
OpenPublic

Mock History

Current Revision

Mock Description

Rebuilding Diffusion for better browsing, less clutter, and persistent navigation. In anticipation of a more "branch dependent" world after T5000.

This is reasonably well thought out, but still completely "in mock form".

Event Timeline

avivey added a subscriber: avivey.Jun 8 2017, 3:57 AM

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?

Gah I searched "mockup email" not Pholio..

chad added a comment.Jul 10 2017, 3:40 PM

@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.

chad added a comment.Jul 10 2017, 4:27 PM

Gonna try the button and see if it sucks.