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:

See some discussion of SELinux in T4947. We'd prefer to find a way to detect that SELinux or AppArmor are running, and warn the user only if they are affected. We've generally had much greater success with raising specific setup warnings during setup than with putting notes in documentation (which users often do not read). We do not currently have a test for SELinux / AppArmor, although it is possible that these tests are straightforward.

Third-party applications which assume dateModified means "last 'meaningful' update" are written incorrectly. It does not mean that, it is not documented to mean that anywhere, and it is clear from the code that it doesn't have this behavior. It is unreasonable to assume that the only possible purpose of this field is metric extraction. This field is a low-level field which serves a different set of goals. It explicitly does not serve metric extraction goals.

Ah! Okay, cool. Not really PEBCAK, I need to fix that dashboard too and it's super confusing that it does something weird/different with no clues about it. I just wanted to see if anyone caught major issues with the new one before swapping it.

In fact it breaks various monitoring/statistics depending on last update

System-specific configuration like SELinux and systemd is outside the scope of Phabricator. See T4200 for discussion.

https://secure.phabricator.com/book/phabricator/article/diffusion_uris/#observe-a-repository

"Last Update" is low level, and includes some actions which do not appear in the task history. This is expected.

Inlined patches are now highlighted more nicely in HTML mail.

The default is still

That's not expected, but I can't immediately reproduce it. Here's my local install, note that D4 appears in "Ready to Review" even though I (admin) am only a reviewer via project membership in Stonework (a project):

I also agree with @chad in the general sense -- this use case seems pretty weird to me and is entirely unlike anything we're aware of in other installs. If email notifications are deficient in some way, we'd prefer to address that.

I suppose you can arc set-config browser <something>, where <something> is a script which copies argv[1] to the clipboard and then exits, then run arc diff --browse.

Roughly, you should be able to:

You can subclass MetaMTAEmailTransactionCommand, following DifferentialActionEmailCommand (which does Differential stuff) and ManiphestPriorityEmailCommand (which is a better example of implementing an individual command), to implement !hahaha-yes-i-definitely-reviewed-this-hahaha which applies !accept only for small diffs.

Here's my technical plan on this:

We can't easily link to an #anchor from email because the transactions that render in email are different from the transactions that render on the web. For example, T10493 is a case that specifically shows a transaction in email but not on the web. Since it doesn't exist on the web, we can't easily generate an anchor to the corresponding transaction because no web version of that transaction exists. This behavior is not unique to that transaction type. Anchor generation is also more complex than this for other reasons (for example, transaction are grouped, aggregated and reordered at display time, and these changes affect which anchors are available).

D15942 restores the project tag transaction to the first mail about an object:

I guess this originally had several different parts. My thinking on the parts are:

I think we're mostly unsure what we want to do here.

Yes. I think this has two general components:

These tattered edges are an expected consquence of destroying objects, and the Phabricator upstream will not help you fix them. We strongly recomend disabling or archiving objects instead.

Thanks, try HEAD?