Developer Migration
Click the star button at the top of this page!
In the settings tab (e.g., https://github.com/YOUR_GITHUB_ID/presto/settings) of your existing Presto fork, change the Repository name from presto to trino and click Rename.
In the existing clone of your Git repository, you should have two remote repositories, one for your fork and one for the upstream. You can see remotes by running the following:
git remote -v
origin git@github.com:YOUR_GITHUB_ID/presto.git (fetch)
origin git@github.com:YOUR_GITHUB_ID/presto.git (push)
upstream git@github.com:prestosql/presto.git (fetch)
upstream git@github.com:prestosql/presto.git (push)
The first is normally named origin and tracks your fork of Trino. The second is normally named upstream and tracks the master Trino repository.
To update the URL for your fork of the Trino repository, run the following:
git remote set-url origin git@github.com:YOUR_GITHUB_ID/trino.git
To update the URL for the master Trino repository, run the following:
git remote set-url upstream git@github.com:trinodb/trino.git
Finally, verify the URL was successfully changed from prestosql to trino, that origin points to your GitHub user ID, and that upstream points to trinodb:
git remote -v
origin git@github.com:YOUR_GITHUB_ID/trino.git (fetch)
origin git@github.com:YOUR_GITHUB_ID/trino.git (push)
upstream git@github.com:trinodb/trino.git (fetch)
upstream git@github.com:trinodb/trino.git (push)
When Presto was moved from the io.prestosql Java package to the io.trino package, all files had to be moved, and all import statements updated. The modules were also organized into subdirectories. For example, trino-main is now in the core directory, and trino-hive is in the plugin directory.
When rebasing a change that was originally created against the io.prestosql package, the rebase will result in conflicts for all the import declarations. To simplify this process, we recommend that you take a multi-step approach to rebasing your work.
- First, rebase the change onto the last commit using the
io.prestosqlpackage (before the repackaging). This eliminates any conflicts that may have occurred before the code was repackaged. - Next, rebase the change onto the first commit using the
io.trinopackage. This ensures that conflicts are limited to only moved files andimportchanges. - Finally, rebase the change onto the current
masterbranch commit.
Since the Java package rename involved moving all the files, git will not detect cherry pick/rebase changes correctly by default.
Configure git to detect file renames when many files are changed within single commit:
git config merge.renameLimit 0
Once all of your work is rebased to io.trino, you may wish to unset this property:
git config --unset merge.renameLimit
If you have a small change, or a change containing a single commit, we recommend you use the following simple three step approach.
Always create a backup branch before starting this process. That way if the rebase goes really wrong, or you type the wrong command, you can start over.
Checkout the work containing your existing work, then create a copy of it named work-backup:
git checkout work
git branch --copy work work-backup
Rebase your existing branch on the last io.prestosql commit:
git rebase prestosql-last
Build the branch to verify that there are no existing problems:
./mvnw clean install -DskipTests
You may want to run the tests for any modules you changed to verify that everything is working before continuing.
Rebase your existing branch named work on the first io.trino commit:
git rebase trino-first
Build the branch to verify that there are no existing problems. Since there are only import changes, you should not need to run any tests.
Rebase onto master, as usual:
git fetch upstream master
git rebase upstream/master
Build the branch to verify that there are no existing problems. Run the tests for any modules you changed to verify everything is still working. If you have an existing Pull Request for the branch, you can force push your branch, which will update the PR and re-run the CI tests.
For large changes, with many commits, file renames, or import changes, rebasing the work one commit at a time will simplify the work. Since each commit is moved one at a time, if there is a problem, you simply back up one commit and try again. This also allows you to pause the rebase work to do something else.
If you have multiple branches to rebase, start with the simplest one first, in order to get a feel for the process.
Very important, especially for complex changes. See instructions above.
Rebase your existing branch on the last io.prestosql commit:
git rebase prestosql-last
Build the branch to verify that there are no existing problems:
./mvnw clean install -DskipTests
You may want to run the tests for any modules you changed to verify that everything is working before continuing.
Rename your work branch to work-old:
git branch --move work work-old
Record the list of commits that need to be migrated:
git log --oneline work-old...prestosql-last
Save list somewhere. Note that they are in reverse order, so you will need to cherry pick starting from the last one.
Create a new empty branch for your commits.
git checkout -b work-new trino-first
We will move each commit one at a time to reduce conflicts. This will reduce conflicts and allows you to throw away and redo the rebase of a single commit, or stop in the middle of the process, if necessary.
Basic cherry pick performs a normal merge, which may work, but can result in many conflicts on import statements:
git cherry-pick commit_id
Alternatively, you can have Git automatically pick changes from trino-first on a conflict. What typically happens is your changes to the imports are ignored, so you have to adjust them by hand. The easiest way is to open IntelliJ and build the project, which will find all the errors.
git cherry-pick --strategy-option ours commit_id
If you have deleted or renamed a file in the commit, the cherry-pick will stop with a conflict warning for these files. Typically, this can simply resolved by use git rm to remove the deleted file, or the source of the file rename.
After migrating each commit, build on the command line using Maven. Since there are only import changes, you should not need to run any tests:
./mvnw clean install -DskipTests
Things that will cause problems:
-
pom.xmlchanges that add dependencies onio.prestosqlartifacts - Renamed or deleted files
Rebase onto master, as usual:
git fetch upstream master
git rebase upstream/master
Build the branch to verify that there are no existing problems. Run the tests to verify everything is still working.