- Mentioned In
- Q14: How ready is Phorge to replace stable versions of Phabricator? (Answer 5)
Q14: How ready is Phorge to replace stable versions of Phabricator?
Q11: upgrade phabricator to phorge (Answer 1)
T15023: Create Phorge, a fork of Phabricator
- Mentioned Here
- T15019: Make Aphlict a node package
T15090: CVE-2022-24765 - Multi-user Git Privilege Escalation
T15046: Add GitHub mirrors for repos
D25004: Update .gitignore to account for package-lock.json
D25006: Add package.json for aphlict
T15013: Better handling of node/npm installation for Aphlict
T15014: Develop a Phorge Release Process
T15016: Update default storage namespace
T15006: Re-brand Phorge
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?
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
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?
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.
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!
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.
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?
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).
FYI, I believe I was able to create a linear history from Phacility's stable branch with the following:
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
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:
Actually, playing around with this more, a simpler way to handle this might be just to do the following:
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
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
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.