How to create merge iteration branch

Iteration Merge

When starting a new iteration of the merge process, a "dirty" work branch is created for resolving the conflicts. It's considered dirty since the merge commit will contain all the conflict markers and thus the tree won't build. This is intentional since it allows us to parallelise the effort of resolving the conflicts.

Setting up

The work repository needs to have the upstream PostgreSQL code as a Git remote in order to merge with it.

git clone [email protected]:greenplum-db/gpdb-postgres-merge.git 84merge
cd 84merge/
git remote add upstream git://git.postgresql.org/git/postgresql.git
git fetch upstream

Merging

While merging is straightforward, make sure the merge repo is rebased on top of the current Greenplum master to make it easier to push the changes back.

git remote add gpdbmaster [email protected]:greenplum-db/gpdb.git
git fetch gpdbmaster
git rebase gpdbmaster/master
git checkout -b iteration_<n>
git merge -Xpatience <sha1 of commit for iteration>

Post-merge cleanups

The Greenplum codebase have some rather obvious differences from PostgreSQL, which will cause a set of merge conflicts. These can be quickly addressed before pushing the dirty branch, to make it slightly less dirty and easier to work with. To identify, look at the git status output for deleted files:

$ git status | grep deleted
deleted by us:   src/backend/optimizer/geqo/Makefile
deleted by us:   src/interfaces/libpq/.cvsignore

• doc/: All the documentation files are removed in Greenplum, with the exception of the reference pages in doc/src/sgml/ref/. The reference pages are required by psql, so they need to be merged and updated, the other can be removed with git rm doc/src/sgml/foo.sgml which clears the merge conflicts there.
• src/backend/optimizer/geqo/: GEQO has been removed in its entirety in Greenplum, so any deleted files there can be removed with git rm`.
• .cvsignore: Any CVS related files can be removed

Updating the Iteration branch with concurrent GPDB changes

git merge origin/master

This creates a merge commit in the iteration branch, and will probably introduce new merge conflicts. You can fix them on the spot if they're not too difficult, or commit the merge conflict markers again and fix later.

Squashing the changes, for integrating into the master branch

If iteration_1 is the iteration branch you're working on:

git checkout origin/master -b iteration_1_rebased
git merge <postgres commit id> # This is the PostgreSQL commit ID we're merging with.
git reset iteration_1 .
git checkout .
git commit # Write a commit message for the merge commit, summarizing the changes.

Push the commit to a forked gpdb repo and then create a PR on Github for review, but finally, you can not depend on the 'squash' or 'rebase' button of the PR to push, instead push the code into gpdb master directly.

git push gpdbmaster iteration_1_rebased:master

Note: it's important that the iteration branch is up-to-date with GPDB master before doing this. Follow the "Updating the Iteration branch with concurrent GPDB changes" instructions to do that.

Example

You can check out the 9.5 merge branch creation notes:
https://github.com/greenplum-db/gpdb-postgres-merge/wiki/How-the-iteration_REL9_5-branch-was-created