You likely have a diff which isn't JSON-encodable (for example, it affects non-utf8 files). T5955 is probably the pathway forward here.

You can print it to a PDF.

I wonder why path "/var/repo/M/" is empty?

Oops, collided midair there. I'm just going to redirect this into "write docs".

We do not intend to ever implement this. It is intentional that adding and removing projects never affect policies.

It is intentional that anyone who can configure the application (in this case, Maniphest) can edit all the forms for it (and can see them in order to edit them), so it's expected that you can manage and reconfigure the form in configuration UI.

f4d47d93fd8a56f918e4cfa72bf96d6997955a8d is not in the upstream. We do not support forked versions of Phabricator.

Yeah, I agree your suggestions are more clear (and "Entire Diff" would be a little murkier).

We do not support the Bitnami image.

There is no such option.

If you already have a branch named arcpatch-D69, it is intentional that we do not overwrite it. You may have made local changes there, and it would be very bad for us to destroy your work.

Minor tangential discussion in T5297, too.

(And, obviously, all of this could be way more clear in the UI.)

Sorry, this actually is expected, if the resource pool is totally empty to begin with. Here's why:

Yeah, use phid.lookup.

See Planning.

I was able to reproduce the error message with the obvious, invalid input:

I'm going to close this out since I think there's no way for the upstream to move it forward for now, but file another issue if you hit a second wave of stuff or reopen this later if, e.g. all the fixes were terrible no-good garbage.

I'll upstream regex changes if they include unit tests.

After the above, I ran arc diff origin/master --trace to update the revision. Got approximately the same screen (with "Differential Revision" now populated), saved and exited, got a clean update (see D15002).

Oh, you're reporting that updating causes the error, sorry. Let me try that.

I can't reproduce this. Here's what I did:

Upgrade Phabricator to rP5592e59 or newer, then try again.

https://secure.phabricator.com/book/phabricator/article/forms/

D15000 will make capturing no text mean "the whole file", and documents the behavior. You can either change your regexp to not capture "0":

Well, maybe that's overkill.

I believe D14307 changed the behavior from "fatal horribly" to "work". It's possible that capturing 0 meant "whole file" at some point (although I'm confused by T6303 if it did) but I think that was accidental and don't believe we suggested/recommended/documented that anywhere.

Instead of the line being 0 (meaning whole file)

See T5920#131011 for prior discussion.

I largely can't reproduce this. Here's what I did:

Alright, I think you should get different behavior at HEAD for both of those issues. No promises it will be correct, but let me know if those changes just uncover a second series of errors.

I also don't think it's wholly unreasonable to change the prefix rule to be stricter, but I think getting rid of the username@ stuff will moot it in all realistic cases. We could look at the rules after the next Conpherence update if we want to reintroduce the username@ rule.

The mail looks like this:

Phabricator strips the prefix if it is present, but does not require it to be present, and attempts to route all mail for the domain it is given.

I intend to remove username@domain.com causing interactions with Conpherence.

(Allowing Phabricator to receive mail at domain.com and also having real mailing lists and users at that domain is still a bad idea, because the two namespaces will collide, but few normal addresses resemble Phabricator object addresses so the practical badness is low -- almost no one has D832@mycompany.com as a real address.)

The second (or third or fourth or whatever, depending on how we're counting) Conpherence issue I'm unsure about.

"Array to string conversion" is a bug. Once that's fixed (by D14996), the user will start getting some kind of error email instead (the bad conversion was occurring while trying to compose an email to notify the user about an error). That error email may describe an upstream bug, or may describe user error. The stack trace doesn't have enough information for me to guess.

The first error is happening while we're trying to generate an error mail, so this maybe quite a deep rabbit hole, but that first surface error looks straightforward.

I've marked D14995 as fixing this, but only commits parsed after the upgrade will have author dates shown.

There's currently no way to create those relationships via the API (see T5873; see also T10034).

Oh, sorry, I was agreeing with you ("points to something environmental").

Yes, the trace implies your entire environment is unsound. RocketLoader (T9716), mod_pagespeed (T4854) and other technologies which rewrite page content and Javascript can sometimes cause this, if you have any of that stuff enabled.

I can't reproduce this. Here's what I did: