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?

I believe this was resolved by the introduction of the "query overheating" mechanism, described in T11773.

I'm going to merge this into T5815, which is a more general discussion of action queues.

I can't reproduce this; we can't move forward without reproduction steps.