These changes are live on this install:

These changes are now live on this install.

I made some headway on this but I'm feeling really icky about it and I think I may want to try making PHUIRemarkupView more powerful and moving away from PhabricatorMarkupInterface first.

Fair enough. I don't plan to pursue this, as written. We've seen very little interest in this, and it's not clear to me that it's the best solution to any problem.

In T1279#176531, @epriestley wrote:

"reviewer list" referred to an element which was removed in 2013, and replaced with this one, as part of this task:

Bugzilla's whining feature is about sending task query results via email, while Herald can only react to single tasks being created or updated.
So I am afraid this is not a complete duplicate of T6491.

In T10640#166457, @Taskle wrote:

the UX problem here for us is that all of our employees are using global search when they don't realize it because it's top right when they go to the phab homepage, when in reality they only use Phab for Maniphest tasks.

D15962 attempts to guess the user's timezone by using the Intl API. This appears to be very accurate in Chrome on OSX, but useless in Safari/Firefox.

I'm going to close this as resolved, since I think we've substantially addressed all of the followups or there are now more narrow tasks with more focused problem descriptions available. In particular, from above:

I'm going to close this since I don't think there's anything we plan to act on here.

Presuming resolved by D15710.

You can likely do this:

One other possibly-bad idea I had was to show only one of these:

I think it actually aligns in practice (e.g., see Differential).

unintentional for a 2-minute mock. See Differential.

v4 moves "assigned" to gutter, and removes Authored (which is the first transaction).

Dunno this feels more heavyweight to me, personally. Probably because this path signs us up to always show Tokens.

Tokens being its own separate island seems conceptually fine to me, although I tend to agree that subscribe is maybe a little weird to disconnect.

Yeah, should be no problem to do mobile magic if that seems like the most promising way forward.

One thing I think about with these actions (flags, subscribe, tokens) is they are personal actions as opposed to object actions. That is, they are for me specifically, and not really affecting the underlying object. It's one reason I think pulling them out feels ok.

lol :)
I don't really like hiding them, but for limited-height-screens... There's just not enough really good solutions.

Oh, notable community member @avivey also raised a concern about hiding options in a dropdown in T8172#117058. :)

I've historically pushed against hiding actions in a submenu, since I think it's a pretty big negative for usability. I'm not totally opposed to heading in that direction but I personally prefer the space being used for actions over any other content. At least today, some of the actions also communicate stateful information ("Automatically Subscribed" shows your subscription state, "Flag for Later" shows the current flag).

Not thrilled about this:

• Arguably, these actions are more used than the actions that are left above the fold. Maybe they should sit on the first part of the main view, like Diffusion's "View Raw File"?
• What happens when we have a 3rd/4th button-worthy action?

The "pull the whole panel out as a curtain widget" approach might also work better for third-party extensions and Phrequent, which isn't enabled on this install but is technically part of the upstream. Maybe the pathway forward there is "delete Phrequent + no support for extending this", of course.

These would become "Unsubscribe" and "Revoke Token" in the same spot?

D15961 adds a timezone correction workflow, including a temporary "ignore conflict" option. This flag is cleared after the next timezone change.

Other issues:

Yes, but I is also reported by jsHint: https://github.com/jshint/jshint/blob/2.1.4/src/shared/messages.js#L195

jshint linter only allow W and E prefixes - https://secure.phabricator.com/diffusion/ARC/browse/master/src/lint/linter/ArcanistJSHintLinter.php;2234c8cacc21ce61c9c10e8e5918b6a63cc38fc8$145

jshint version is the latest: jshint v2.9.2. I'll add more infos to this ticket soon...

After D15959, user.search should support "find all non-disabled human users", likely with parameters in this vein:

I think T5953 is a better fit for that in the upstream.

I disabled the APC extension but still had the same issue. I'll try deploying on CentOS 7 when I have some time.

FWIW is something like user.edit on the table? We'd like to be able to pre-create users with specific information such as 'real name', and a particular external account linked.

Specifically, what version of JSHint are you using would be most helpful.

Software versions and steps to reproduce are required information for us on bug reports. Do you mind filling this out please? See Contributing Bug Reports.

If there's interest in prioritizing this directly or via T5000 I'm comfortable committing to an 80-hour estimate to support these use cases:

Another possibility is that we just build this behavior (intercept and react to ref changes) as an extension point prior to the Herald, and then you can implement whatever magic you want. I suspect very few installs want the default behavior of git push origin mybranch for arbitrarily named branches to be anything except "create a branch".

FYI we'd mainly be placing devops engineers in the "allow push any branches" project group, so that in the case where we need to hotfix production, authorized users can create a branch in the remote to create a release from it.

I'd expect there to be either per-repository rules (like "Tracking Branches" for repositories right now), or Herald-based rules "on branch hook, convert to Differential Revision action" that would allow Phabricator to determine whether a branch is allowed in the remote or not.

So your desired behavior is that git push origin develop should create a revision, instead of creating a new branch in the remote like a normal Git repository would? How would users create new branches in this model?

In T5000#176433, @epriestley wrote:

non-master branches in the repository would be Differential Revisions

I think the closest match for this is T10691 (GitHub-like forking). I'd plan to implement forking very similarly to GitHub.

I don't plan to ever encourage users to create un-namespaced personal branches in the remote because I believe this process doesn't scale well to a large number of users. Much of the value of forking in my mind is giving users who want to do this (particularly, under the "git push = save changes" mode of thinking) a namespaced place to do it.

non-master branches in the repository would be Differential Revisions

To me, I imagined this task would be supporting something rather like:

You'll still need to go there and fill out all the stuff you would have filled out in your commit message. That is, this flow would drop you at the screen right after you copy/paste:

Try disabling php-apcu and other performance related extensions. Some of them (like APC) are known to cause segfaults or other issues, so unless you actually need to have them installed, I'd suggest disabling them and see if the issue still occurs.

This sounds like an issue with either git clone or the SSH client installed on the build machine itself, and not Phabricator. I don't believe upstream offers support for configuring build agents (they don't offer support for envionment issues on machines that host Phabricator, let alone environment issues on machines that Phabricator uses for builds).

I think this should just be lumped under "username aliasing" in T4267#47083.