Migrating a branch from fcm to git#

Important

If migrating an old trac ticket, please make sure to,

Cross-link between both the trac ticket and github PR/Issue
Add a git_migration:#NNN keyword to the trac ticket to avoid duplicate migrated tickets

This page is intended to act as a guide when migrating branches from fcm to git after the initial git release. It assumes that you have already created a fork of the repo you are migrating to.

Tip

The process below involves creating a patch file based on your fcm branch, and then applying it to git branch taken from the same branching point. For convenience, the git_migration tag is provided as a branch point in both fcm and git. However all fcm revisions and tags have a direct equivalent commit on git - tags will have the same name on both, revisions of specific commits will need to be manually aligned with a commit hash by comparing commit messages.

Optionally, create a new branch in fcm using the tag git_migration. Then merge your development branch onto this one, eg.
```
fcm bc --type=dev branch_for_migration fcm:lfric_apps.x_tr@git_migration
...
fcm merge fcm:lfric_apps.x_br/dev/USER/BRANCH
```
Resolve any conflicts and then commit these changes to this branch, fcm ci.
Create a patch file from your new branch at the migration point,
```
fcm bdiff >> /path/to/branch_diff.patch
```
Move into your git clone and create a new branch with the same start point as your fcm branch. If you are branching from an untagged revision, you will need to manually find the relevant hash for that commit from the git log by comparing commit messages.
```
git switch -c <branch name> <tag to branch from>
e.g. git switch -c new_migrated_branch git_migration
```

Apply the patch file onto the git branch,

git apply --reject /path/to/branch_diff.patch

If your fcm and git branches are from an equivalent branch point, there shouldn’t be any conflicts applying the patch file. If there are conflicts then these will be recorded in *.rej files. The output of the apply command will note any failures, or you can find them by running find . -name *.rej. Fix any failures you find and then commit the changes.
Finally, all branches will need to update to the initial git release in order to run the test suites. This can be done by merging the stable branch into your new branch. See updating a branch for more details, noting that you will need to use one of the options using git commands for this step.
It may be worth running the test suite to ensure the branch has been properly migrated.

Tip

There will be significant changes to the rose-stem test suites between the git_migration point and the initial git release. Therefore, conflicts are expected when updating rose-stem changes to the initial release. The UM, Jules and UKCA test suites have all had file extensions renamed from .rc to .cylc.