Page Comparison

Why subtree for CIME?

...

Add of CIME5 to ACME:

The existing cime was removed with git rm and the above repeated with

git remote add esmcicime git@github.com:ESMCI/cime.git

...

Updating ACME's CIME from ESMCI:

ACME/cime/scripts/Tools/acme_cime_merge [<repo-to-use>]

Bringing ACME CIME changes back to ESMCI:

(The example code below is from the first time this was done)

NOTE:  if your work on a branch requires changing files in a subtree, be sure to commit those changes separately.  This will aid the future subtree split of those files back to the external.First step is to create a branch that contains the changes you want to move back to the external (ESMCI/CIME in this case).  The branchname should follow ACME conventions.  NOTE: the command below must be issues from the top directory of ACME.

%%First Time Only: git subtree split -P cime/ -b rljacob/acmemerge-to-cime1  (first time)
blogin1: git subtree split --prefix cime/ --ignore-joins -b rljacob/acmemerge-to-cime1  (after there's been merges back-and-forth).
Created branch 'rljacob/acmemerge-to-cime1'
fe8c483486af5b95f24ee64ce45ccb6d6fb6061e
blogin1: git branch
  master
  rljacob/acmemerge-to-cime1
* rljacob/cime-merge

Make sure you have a name for the external's git repo.  In below, "origin" is the usual ACME repo and "esmcicime" is the upstream repo of cime.

blogin1[102]: git remote add esmcicime git@github.com:ESMCI/CIME.git
blogin1[102]: git remote -v
esmcicime	git@github.com:ESMCI/CIME.git (fetch)
esmcicime	git@github.com:ESMCI/CIME.git (push)
origin	git@github.com:ACME-Climate/ACME.git (fetch)
origin	git@github.com:ACME-Climate/ACME.git (push)

Now checkout the master of esmcicime.  Note that the presence of the mpas-o module will cause a message.

blogin1[156]: git fetch esmcicime
blogin1[156]: git checkout esmcicime/master

warning: unable to rmdir components/mpas-o/model: Directory not empty
Checking out files: 100% (7985/7985), done.
Note: checking out 'esmcicime/master'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at b496e53... Merge branch 'jgfouca/skybridge_working' (PR #7)
 
blogin1: git branch

* (HEAD detached at esmcicime/master)
  master
  rljacob/acmemerge-to-cime1
  rljacob/cime-merge

At this point, you're in a "Detached head state".  You can ignore the message about mpas-o.  mpas-o becomes an untracked file and will be ignored by git in the rest of the operations.

From the detached head state, make a branch from which you'll bring the new code to cime's master.

blogin1: git checkout -b rljacob/merge-from-acme1
Switched to a new branch 'rljacob/merge-from-acme1'
blogin1]: git branch

  master
  rljacob/acmemerge-to-cime1
  rljacob/cime-merge
* rljacob/merge-from-acme1

blogin1[173]: git status
On branch rljacob/merge-from-acme1

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	components/mpas-o/

nothing added to commit but untracked files present (use "git add" to track)
blogin1[174]: 

Now merge onto the branch you just created the changes that are on the branch created by the subtree split (the first command above).

blogin1[175]: git merge rljacob/acmemerge_to_cime1

If you're lucky, there will be no conflicts and you'll be asked to make a commit message.  If there are conflicts, resolve them with the usual procedure, add the resolved files, and commit (and finally enter the merge commit message).

You can now push the branch containing the code for the external and merge it to master using the external's procedures.

Two-step workflow option (under development as of March 2017)

Here are the commands for a 2-step process that Andy used successfully, March 2017. Need to integrate with above description once we settle on a process.

Previously, ESMCI/CIME was tagged with "cime5.2.0", and that code was brought into ACME. The process below (recommended by Rob) is a 2-step process. First the changes in ACME are merged into a branch coming off of that tag. A second step merges those changes into master. One nice part of this process is that the first step has mostly ACME changes, so conflicts are can mostly be reconciled by taking ACME version. The second step has just true conflicts, which will not be very many.

NOTE: need to pick better branch naming conventions in the future.

...

.

ACME/cime/scripts/Tools/acme_cime_split [<repo-to-split>]