If you'd like us to look at it, please file a separate bug report with reproduction instructions, following the guide in Contributing Bug Reports.

I think this might have broken one of our Herald rules. The rule in question is an Object rule for Commits on a Project and will open an Audit whenever a commit is made to a repository that's tagged with this project.
At least it did ~2 month ago and after the upgrade it just won't fire. Just using the test console on a new commit in a repo tagged with the project simply says "Rule failed".
To make sure i already removed all the other conditions from it so it only states "always".

Awesome! Sorry for the churn here -- I think we have a brighter future on the other side, but have to break a few eggs to get there.

This does not describe a bug in Phabricator. See Support Resources for help understanding available support resourecs.

Thanks that did it! Still working through an issue with one of our more *ahem* exotic applications, but I suspect that'll be a more involved refactor on our end.

Okay, I saw php7.1-mysql and just wanted to make sure you were aware.

I know that php7 is not supported. I mentioned that I switched php to 5 version

Although I earlier (in T6630#85282) felt like it was reasonable to consider separating Audit and Diffusion, there are now more existing or planned integration points and I think this approach is significantly less reasonable than the "merge them" approach. It also doesn't seem to be causing any problems on real installs.

This doesn't reproduce for me and we don't support third-party code, but it's entangled with T11114 and can stick around until I get rid of the old table.

Particularly, this does not reproduce against the upstream. All patches can be re-run in order with ./bin/storage upgrade --no-quickstart --namespace ..., and we do this somewhat regularly. This process runs cleanly:

We've formally frozen this method after D17158. The UI now encourages project.edit.

Can't reproduce this - assuming fixed?

(Note that this kind of requests are normally not supported - see Support Resources. This is not likely a bug in Phabricator).

The order of stopping/starting daemons/webserver isn't important, as long as both are down during the upgrade.

This doesn't appear to be a feature request or bug report, so closing out. If you need support with Phabricator, please see Support Resources.

Some parts of KDE use git notes fairly extensively for certain specific workflows.
How difficult would it be to have Phabricator permit pushing Notes, even if Phabricator itself didn't do much with them (doesn't need to display them)?

Intentional; see T12026 and T12027.

Thanks a lot for the quick fix here. Works great now. Was the change to get rid of potential arc commands in the Diffusion review intentional or is that also a bug?

Presumably resolved by D17171?

Thanks for the report. This should be resolved at HEAD of master. Let us know if you run into anything else.

This was collateral damage from D17164.

I dunno, I get this error every time. I just tried it again patching back on the same repo that generated the diff:

hmm, that's pretty much it. lemme make sure i'm not missing anything

Oh and libphutil is at c5848b71c10 and arcanist is at ade25facf

I am also at HEAD and cannot reproduce that error. What steps am I missing?

1. Create a diffusion review with arc diff
   1. Run arc patch <ID of review>

Hurray, thank you!

Please include reproduction steps. This is always required on every bug report.

After D17169, the clusterize command, the error message, and the documentation should be more helpful in anticipating and resolving this situation. (The documentation may take ~24 hours to actually regenerate.)

oh ok, I think I can do that

we can probably ditch that outright?

You should be able to return a list of appropriately configured PhabricatorEditEngineProfileMenuItem objects as builtins, rather than defining a new class for each application -- since "Create Task" is just "EditEngine link to the create task form", etc.

I also think you have some special magic that turns "Create Task" into a mini-menu automagically - we can probably ditch that outright?

I think I need to make PhabricatorProfileMenuItem files for each "default" I want to ship?

I marked D17168 as fixing this -- it just makes the replacement migration more robust, but I think that's the best we can do from the upstream. No idea how null ended up there in the first place, but I'd guess we have no way to figure it out and our lives would be no richer for knowing.

Aha, of course. Thank you!!

You should be able to safely update these rows to have '' instead of NULL, then continue:

I'd be happy just to have a good workaround, since I don't think we're particularly attached to these mostly-contentless rows. My ideas for possibilities so far are:

• Delete the offending differential_hunks rows manually. I worry that this might cause some inconsistency.
• bin/destroy the revisions containing the offending hunks. This seems a bit heavy-handed though.

Ah, sorry, I overlooked that you're using edges.

Doing that without defining getFieldTransactions() in my class yields this exception:

Transaction with key "1" has invalid type "devTestPHIDs". This type is not recognized. Valid types are: update, comment, title, summary, testPlan, reviewers.add, reviewers.remove, reviewers.set, repositoryPHID, tasks.add, tasks.remove, tasks.set, view, edit, projects.add, projects.remove, projects.set, subscribers.add, subscribers.remove, subscribers.set, phabricator:auditors.

Oh -- try subclassing DifferentialCommitMessageCustomField instead of DifferentialCommitMessageField directly?

Ah ok I was just thinking that if anything happened to be depending on the state of the working copy then removing the -u argument could affect those.

Thanks for the help Evan. I've gone through and converted everything as you suggested. The conduit method then started telling me

The other side of the Conduit call still issues an hg (or git, or whatever) command in most cases, but sending everything through Conduit means a different host (one which actually does have a working copy) can give us the answer if necessary.

They shouldn't interact -- T10753 is mostly about clustering. When Diffusion and the daemons need to ask questions about a Mercurial repository, they're supposed to issue a Conduit call so Phabricator can get an answer by asking another host if it needs to. In a few cases, they currently just issue an hg command, which only works if the repository is present (and up to date) on local disk.

This might depend on T10753?

乁༼☯‿☯✿༽ㄏ

I'm just going to merge this into T9548 since I think bundle2 support will fix it?