For projects that were tracking upstream previously and able to merge, would this not be a matter of a Git config update to add or swap remotes then merge?

Or what are some initial thoughts on this process?

Added related task T15006 since it could likely serve as a reference for this one... Please undo or stop me if I'm overstepping boundaries

Thanks for creating this. I think there have been some notes in comments that mention having to make several updates

• T15016: Update default storage namespace
• T15013: Better handling of node/npm installation for Aphlict, more comments in D25004, D25006

Also there might need to be some coordination with T15014: Develop a Phorge Release Process, for the first go at least

Hi all,

My company are currently Phabricator users and have been watching the Phorge developments with interest in the last few months. It's been great to see the project taking shape!

We were wondering if anyone can answer: are any migrations from Phabricator to Phorge dependent on https://we.phorge.it/T15006? Is the eventual idea that Phorge will be put on GitHub, and is the branding ticket a blocker for that?

Thanks :)

@io for GitHub we have a task (T15046)

Great, thanks for the info.

Hey, all;

We are now at a decision point where we either install Phorge from Scratch or migrate Phabricator to Phorge.

Our situation is: We have already started using Phabricator for internal purposes and we have customized the forms and added quiet a number of custom fields. Also we have already a few dozens of Tasks and tracked commits, we would like to keep those infos when migrating to Phorge.

If necessary we can setup Phorge and redo the customizations manually. However, we would prefer to do a migration, but only if there is a reasonably working migration path. I am willing to put effort into the documentation (after doing the migration) if that is necessary, feasible and makes sense in any way.

Hello, @Higgs

As of right now, we have made no changes to the database and other "internals" - our work has been focused on rebranding as "Phabricator" is a trademarked name. For this reason, a rough migration path would be to check out the master branch of rP, copy the config directory from Phabricator to Phorge, and then point Phorge to your Phabricator database. I have tested it myself locally and it appears to work, however; if you have any issues feel free to ask a question on Ponder here and we can get back to you!

(And yes, we are aware that viewing rP Phorge does not work... see T15090)

I've written https://we.phorge.it/w/installation_and_setup/update_from_phabricator/, and I think it's basically ready for simple case (and considering we're still compatible with Phabricator in all technical aspects).

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?

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.

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

Oh actually they do work now - never mind

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?

I'm not familiar enough with Git to know how to fix that specifically. I know that we merged all changes into our fork after Phabricator pushed changes to stable (last revision June 14, we pulled in changes July 25). It looks like a linear history from this though I could be missing something. @avivey you took care of the merge, do you have any thoughts here?

In T15026#2814, @jeremy.norris wrote:

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.

That's a good idea, I'll make that change right now.

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.

I suspect that this may require a bit of Git surgery to resolve (i.e., reset Phorge stable to be based off Phabricator's stable branch, then do targeted cherry-picks or squash merge of Phorge's master onto Phorge's stable).

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?

maybe the default instructions should assume "no local changes" and use git reset?

re the conflict, I did not expect that - are these files automatically created when running the old version of Aphlict?

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)?

As for the Aphlict: I believe the files were created by the npm install ws command as documented here: https://secure.phabricator.com/book/phabricator/article/notifications/#installing-node-and-modules.
But since T15019 directly committed those files into Git here in Phorge, they can cause a conflict during git pull during a Phabricator => Phorge migration.
I'm not 100% sure what the best path forward is (I'm not much of a node.js person unfortunately).

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

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

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

Actually, playing around with this more, a simpler way to handle this might be just to do the following:

Phorge:

git checkout stable
git remote add phacility https://github.com/phacility/phabricator.git
git fetch phacility
git merge -m "(stable) Merge phacility/stable" phacility/stable

Arcanist:

git checkout stable
git remote add phacility https://github.com/phacility/arcanist.git
git fetch phacility
git merge -m "(stable) Merge phacility/stable" phacility/stable

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

I think we might want to add the following commands (as listed in D25006's test plan) to the migration guide for Aphlict users (probably after the git pull is completed for phorge):

cd support/aphlict/server/
rm -rf node_modules/
npm install --no-save

The --no-save part I think is important to make sure that package-lock.json isn't locally modified (see https://github.com/npm/npm/issues/17761#issuecomment-334200107).

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

a side-note: it's kinda hard to chase down the Aphlict breakage instructions, partly because it's over a year old and partly because I wasn't paying attention at the time. When making breaking changes at the future we should do better at writing the instructions asap and adding them to the relevant changelog.

Are there plans to merge the latest Phacility/stable branch into Phorge/stable branch in order to facilitate upgrades without having local merge commits being created?

In T15026#3071, @jeremy.norris wrote:

Are there plans to merge the latest Phacility/stable branch into Phorge/stable branch in order to facilitate upgrades without having local merge commits being created?

There may be plans to merge Phabricator/Phacility branches to Phorge branches. See T15006: Re-brand Phorge.

we've decided to add git reset --hard to the instructions to avoid the merges and simplify the stable issue, avoiding the merge from multiple branches.

In T15026#3073, @avivey wrote:

we've decided to add git reset --hard to the instructions to avoid the merges and simplify the stable issue, avoiding the merge from multiple branches.

Wouldn't it just be easier for users if the current Phacility/stable was merged into Phorge/stable, thus avoiding the need to issue git reset --hard?

In T15026#3074, @jeremy.norris wrote:

Wouldn't it just be easier for users if the current Phacility/stable was merged into Phorge/stable, thus avoiding the need to issue git reset --hard?

The complexity of the merge tree made us doubt we can continuously successfully produce a clean, fast-forward merge when a user runs git pull.

Ae we going to close this?