There is no need to make a modern software compatible with PHP 5.x so I can agree to this change.

Happy to create empty pages (I somehow feel that a wiki page with a fat TODO might be marginally better than a 404 :))

thanks - not technically a dupe, because there's no ticket, but D25050 would fix those.

@jupe these 404 errors appears because the documentation pages linked were not yet created.

Thank you Cigaryno.

If you want to copy the Diviner doc from https://secure.phabricator.com or https://we.phorge.it, you may create documents at Diviner or Phriction and set an edit policy if needed. To disable applications you don't need, click More Applications in the homepage, click Manage and then Uninstall on applications you don't need on your instance. To migrate from Phabricator to Phorge, see this manual.

@Cigaryno Phabricator ( for now )

@SmoothPlay are you using Phabricator or Phorge as server software.

This task is mostly done so I think it should be closed as resolved.

arc liberate

Linting

Great that works perfectly thanks

There are no more Phabricator references in Diviner so I think this revision may be accepted.

In brief, Maniphest is for bug reports or feature requests and Ponder is for asking questions about Phorge.

(should also include the rHP -> /home/ stuff)

Done - deleted phabricator books.

I've updated the guide with @jeremy.norris's Aphlict instructions, and also a section about configurations we might change later.

In T15026#2840, @avivey wrote:

the Aphlict change sounds simple enough to just add to the migration guide - it's going to happen at the same time for basically everyone anyway.

Edit: Looks like this issue was raised in the PR D25006#216

In T15026#2841, @jeremy.norris wrote:

FYI, I believe I was able to create a linear history from Phacility's stable branch with the following:

Phorge:

git checkout master
git remote add phacility https://github.com/phacility/phabricator.git
git fetch phacility
git checkout -b stable_linear phacility/stable
git merge -m "(stable) Promote 2022 Week 37" origin/master

Arcanist:

git checkout master
git remote add phacility https://github.com/phacility/arcanist.git
git fetch phacility
git checkout -b stable_linear phacility/stable
git merge -m "(stable) Promote 2022 Week 37" origin/master

You can view the results on my Github here:
https://github.com/norrisjeremy/phorge/tree/stable_linear
https://github.com/norrisjeremy/arcanist/tree/stable_linear

FYI, I believe I was able to create a linear history from Phacility's stable branch with the following:

the Aphlict change sounds simple enough to just add to the migration guide - it's going to happen at the same time for basically everyone anyway.

Since the user base is probably pretty small for stable in Phorge, I wonder if it could just be deleted altogether? And then create a new stable in Phorge, that is based directly off of Phabricator's stable, then perform a squash merge or cherry-pick of Phorge master into the new Phorge stable?
I'm not 100% certain how Evan handled promotions of Phabricator master into stable (if he just cherry-picked, or he used squash merges or something different altogether)?

re: stable, I'm not sure how the commits actually relate between the now 4 branches.
I considered adding git reset --hard for stable, but I was afraid users will lose local changes.
So you have a suggestion on how to fix the guide for stable?

In T15046#2789, @Matthew wrote:

need to create a username/password passphrase credential with creds for a GitHub account that has write access to the GitHub repos, and set it in the diffusion uris.

I was hoping that wouldn't be the case. I'll create a credential against my account, since it's currently impossible to create GitHub account keys against an orginization.

The master branch in Phorge is linear with respect to Phabricator's master branch, but it looks like the stable branch in Phorge was created by branching it directly from the tip of Phorge's master, instead of using Phabricator's stable branch as the basis.
It looks to me that Phabricator was cherry-picking their master to their stable, so the changeset history wasn't directly linear with their master (hopefully that makes sense?).
So the directions from the migration guide end up creating a huge local merge commit when followed if you were tracking Phabricator's stable branch.

In T15026#2812, @jeremy.norris wrote:

FYI, the guide for migration doesn't seem to work quite smoothly for folks that were tracking the stable branch for Phabricator, because the new stable branch in Phorge does not have a linear changeset history to the old stable branch in Phabricator: if you follow the directions, you end up with a locally divergent stable branch that will contain a local merge commit.
Is there a reason the stable branch in Phorge wasn't created based upon the changeset history of the stable branch in Phabricator, in order to avoid this from happening?

Also, on a separate note, the changes from T15019 cause a conflict when issuing the git pull command:

error: The following untracked working tree files would be overwritten by merge:
	support/aphlict/server/package-lock.json
	support/aphlict/server/package.json
Please move or remove them before you merge.
Aborting

Should some notes be added to the migration guide on how to best deal with this as well?

Oh actually they do work now - never mind

The GitHub mirrors still don’t work yet, those reps are empty currently.

Also, should the migration guide & installation guide point users to the Github mirrors?
This might help avoid undue load on we.phorge.it?
I'll note that the Phabricator installation guide always pointed users to the Github mirrors as well.

FYI, the guide for migration doesn't seem to work quite smoothly for folks that were tracking the stable branch for Phabricator, because the new stable branch in Phorge does not have a linear changeset history to the old stable branch in Phabricator: if you follow the directions, you end up with a locally divergent stable branch that will contain a local merge commit.
Is there a reason the stable branch in Phorge wasn't created based upon the changeset history of the stable branch in Phabricator, in order to avoid this from happening?

I'll note that the developer-mode, timezone, serious-business and production-url config settings still use Phabricator in the names

The labs one was me from ages ago before a GH org name was decided on. IIRC the phorge org was already claimed and I just wanted to be squatting on something that could.be used down the road. Happy to delete / change ownership / whatever else

In T15046#2762, @jeremy.norris wrote:

In T15046#2761, @jeremy.norris wrote:

It appears there are not any public repositories yet, is this intentional?

Actually, what is the correct Github organization? In the description for this task, the link is to (which is where I initially looked and saw no public repositories):

https://github.com/phorgelabs

But then in the comments above, the link is to (which does appear to have public repositories that are empty?):

https://github.com/phorgeit

In T15046#2788, @MacFan4000 wrote:

@avivey I see that the repos currently access GitHub anonymously. For auto mirror to work you need to configure a valid credential. By this I mean you need to create a username/password passphrase credential with creds for a GitHub account that has write access to the GitHub repos, and set it in the diffusion uris.

@avivey I see that the repos currently access GitHub anonymously. For auto mirror to work you need to configure a valid credential. By this I mean you need to create a username/password passphrase credential with creds for a GitHub account that has write access to the GitHub repos, and set it in the diffusion uris.

In T15046#2762, @jeremy.norris wrote:

Well that didn't work: T15114: Can I create tasks?

I'll remove myself from trusted contributors just to test.

The form ( https://we.phorge.it/transactions/editengine/maniphest.task/edit/2/ ) needed a security policy. I think that should fix the problem?

https://secure.phabricator.com/book/phabricator/article/custom_fields/ custom fields allow you to set the required property in configuration. I'm not sure if you can use this to override a default built-in field but you could possibly replace the built in field with a custom field with same/similar name and type: users.

I would say the current create forms are fine, there should be 2 edit forms, 1 unrestricted one only visible to trusted users, and a restricted one that is only visible to non-trusted users (can be done with custom policy)

I’ll note that there is currently a restricted create form, for Trusted Contributors that allows anything to be changed.

In T15046#2761, @jeremy.norris wrote:

It appears there are not any public repositories yet, is this intentional?

It appears there are not any public repositories yet, is this intentional?

As @avivey mentioned, the GitHub organization is set up. Both Aviv and I have access, and I am willing to add other people in the core team.

We've created https://github.com/phorgeit and started configuring it to mirror the repos.

Process requires 2 forms with the following modifications:

• Create task form
  • Edit Form Configuration
    • Visible To -- All Users
  • Lock/Hide fields
    • Priority
    • Editable by
  • Change Default Values
    • Editable by -- Custom (likely Administrators & other trusted projects)
• Edit task form
  • Visible to certain subset of users (like a project)