None of those screenshots demonstrate inconsistencies on their own.

Okay. I can't reproduce that. Here's what I did.

The "Inline Comments" section shows new inline comments. It does not show inlines marked "Done".

Here's at least one specific reproduction case which still isn't working well:

To summarize the above: if there are two renames, the first one loses information if we don't include the old and new name. Current behavior:

I'm just going to merge this into T11076 since this will happen with the rest of the deployment work there. I expect this to be straightforward.

From the downstream, it seems like the problem may be one specific user wanting to add mirrors to existing repositories:

It's also vaguely possible that we'll add "suggest an edit" (ala T4104) in a generic way, then untrusted users could suggest edits and trusted users could approve them. I don't currently plan to build this as a general-purpose workflow, though.

I don't plan to pursue field-level permissions in any application. They were somewhat recently removed from Maniphest in T10003. That task discusses some of the complications that field-level permissions create in the general case.

(See also T6297.)

You're watching #twitter.

Object rules have the same edit policy as the corresponding object.

Thanks for the report, and for including version information.

Go to /applications/, then click this:

Er, rather, the policy hint is fine since that's the view policy.

Global rules can only be edited by users with "Can Manage Global Rules" permission (Applications → Herald → Configure → Can Manage Global Rules). By default, this is administrators.

Thanks for the report! This should be resolved at HEAD of master, and promote to stable in about 48 hours.

Thanks for the report! This should be fixed in HEAD of master, and will promote to stable in about 48 hours. Let us know if you're still seeing issues after updating or if you run into anything else.

Thanks, those specifics are helpful.

Thanks for the report!

D16006 is the main fix; CORGI is resolved in secret at https://meta.phacility.com/D84.

Fix for this is on meta, but the short version is that it works fine as-is.

Yeah, --force is a little weird as a name given what it actually does.

Maybe --force could even just do that, without needing a new argument, since it already forces argument interpretation as paths? So the behavior would be:

Do you type that explicitly, or would something like find-some-files | xargs arc browse --paths ("force any arguments to be interpreted as paths") be good enough?

It looks like the original user may have just wanted (or been satisfied with) a Diffusion file-line link anyway? Thread is sort of ambiguous:

We could change the URL as a side effect of starting an inline comment, although you'd have to cancel the inline comment afterward.

This is fairly involved in the general case:

D16001 likely provides an appropriate general-purpose mechanism for the user cache pool.

Mystery Query: Where is this coming from?

Summarizing caching for my own benefit. See also T10078, T10077.

It sounds like this is resolved. We almost certainly can not raise a more specific exception.

We may pursue this eventually but there are hundreds of hours of work between where we are today and scalable, no-code-required bot support.