There were ultimately two sort of related requests here, although some of the discussion happened off-thread. Let's call them arc diff --draft and arc diff --try:

unfortumately

The time zone selected below has been auto-detected based on your browser settings

Yeah, current behavior is garbage. Not sure if I changed it by accident while doing other changes or we just didn't run into it before, but there's no technical or product reason for it to work like it currently does.

I suspect it isn't going to get very far because we lose our ability to optimize lookups (I wrote this in the general case as "regexp", but mean "regexp/wildcard" -- wildcards aren't as complex but I think the general case still holds).

Try /wsl_root/src/ansible/ (with a trailing slash)?

The following queries are full table scans:

I don't know how to reproduce the issue, but figured I'd let you know that I'm seeing this in our error logs:

Did you fully restart everything (see Restarting Phabricator) after upgrading? I can't reproduce this and it looks like the kind of thing that could happen if Phabricator was not fully restarted.

We now send HTML mail by default.

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.

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

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.

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

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.

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.

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

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?

non-master branches in the repository would be Differential Revisions

Ugh.

This is in master and live on this install. Let me know if you hit issues with it, especially on mobile. Seems fine on my iPhone 4 but I don't have a ton of devices on hand for testing.

Phabricator doesn't give me an option to say "this commit depends on this other commit, so you can review it on its own but don't try to merge it yet".

Wow, good job! Check out your review at https://secure.example.com/D1234

IIRC, we copy/pasted at Facebook for quite a while -- maybe 6-12 months, circa 2007, before arc and related tools really got built out -- without ever running into wordwrap/whitespace issues.

To install:

Alright, let me sketch out the "missing X account" thing.

Maybe a good way to attack this is to discuss specific notifications. I think the use cases we're aware of are:

Git protocol rewriting appears practical.

The Git wire format for PACK data is very special, here's how you read the length of an entry:

@fooishbar, this task will not address your use case. We will, as closely as possible, implement arc semantics without requiring arc. The primary upstream motivation for this workflow is to provide a stepping stone toward arc which is as similar as possible to the arc workfow, not to provide a new, entirely different workflow which would make adopting arc more confusing and difficult.

Major unknown here is the complexity of decoding the Git wire protocol. The D9599 workflow goes like this:

Two of the three issues discussed above (lock granularity, severity of device enrollment) got tackled. I think I have an attack on versioning hosted repositories, but I'm not going to try to squeeze it in before the release cut today.

D15953 played out more or less as described above. I'm not going to land it before cutting stable this week since it touches Workflow in a couple of ways that might have unforseen consequences, but I expect it to be available in master some time later tonight or tomorrow.

After D12066, we have an upload workflow which gracefully accommodates very large files (progress bars, resumable uploads, no server host needs to handle more than 4MB of data on disk or in memory at once). This flow is activated when you drag-and-drop, and we've successfully used it to transfer reasonably-sized cluster import/export files (1-2GB) for the better part of a year now.

Not sure if this was just a test or not, but it's doesn't look like a bug report. See Contributing Bug Reports for help writing good bug reports.

What does arc which say before you run the final arc diff?

That cleanup stuff should be cleaned up now, so I'm formally pausing this for feedback.

In HEAD of master, keys now have a detail screen which shows a transaction record. Clicking the key name will take you there: