If the answer to (2) is "yes", we should detect that a commit deletes the HEAD ref and remove HEAD before accepting the commit. This may be quite difficult if hooks don't get to run before the HEAD check runs.

Babun pre-installs cygwin PHP usable from the unix-style shell.
PHP extensions can be installed with pact install php-jsonc php-curl.
As for the native PHP builds, you’ll have to tamper with PATH and manual extraction/file permission for extraction.

Not all projects want/need a Workboard

NVM. Not everything was up to date. Hosting forks in phabricator itself made it a bit confusing I guess.

Will the linter config (.arcconfig) somehow point to .editorconfig? Or will you *just have to know* that the text linter uses not only its linter config, but also .editorconfig files?

Adjust charset error message to match new rules (having added CR as allowed character).

First change for T6739

One issue with using dotless domains is that Chrome will not be usable at all, as it does not save cookies.
This is also why this check was originally implemented, to prevent dotless domains; see https://secure.phabricator.com/T754#7045

I’m confused. Will what it parses depend on the languages installed/available and setup on the server?
I would expect the patch parser to recognize patch files of any language, without depending on runtime environment languages.

Ah, so I’m supposed to upload a diff patch that already provides the context. Fair enough, makes sense.

Any update on this? @20after4 are you still working on this?

I can confirm this issue.

Yeah, *I*’m fine, but was thinking about others who may get confused (or me in a week). Sorry for the confusion.

Didn't see all of the inlines before hitting arc land. This fixes up the issues raised (and makes all the code nicer).

This revision should link to the previous one for context - or am I just not seeing it?

Sure, we already patched it. I was just thinking this could be something useful to others as well.

If you migrate from JIRA5 and thus never want to use JIRA6, you can patch Phabricator (libphutil) without the dangerous consequences you would otherwise have when upgrading JIRA later on. (The mentioned workaround above.)

In the end, we grouped the repositories into projects, hacked built-in queries for diffusion per project, and extended the project page to list repositories.

What would you expect as a test plan?

First of all, a bit on our use case: We have a great number of repositories (central project alone consists of >40 modules (which will increase); add tools and lib-forks to that).

The repo hosting guide did not make it clear to me:

Thank you for the fast response and handling!

I guess that would be an argument for two authenticators.
For JIRA 5 the name is the unique key, for JIRA 6 key is the unique key.
That would not provide a migration path, but make their independence and incompatibility (more) clear I guess.