Update fates_next_api to ctsm1.0.dev093

[glemieux]

Description of changes

This PR reconciles differences between release-clm5.0.30 and ctsm1.0.dev093 (https://github.com/glemieux/ctsm/tree/release-clm5.0.30-ctsm1.0.dev093) and then pre-merges these changes into fates_next_api.

Specific notes

This PR addresses #1008 in part. Discussion of release-clm5.0.30 and ctsm1.0.dev093 merge deconflict is in found glemieux#1.

Contributors other than yourself, if any: @ekluzek

CTSM Issues Fixed (include github issue #):

Are answers expected to change (and if so in what way)? yes

Any User Interface Changes (namelist or namelist defaults changes)?

Testing performed, if any:
Both aux_clm and fates regression test suites were run using run_sys_tests:

/glade/scratch/glemieux/ctsm-tests/tests_ctsmdev-release-merge-fullregression
/glade/scratch/glemieux/ctsm-tests/tests_testfates_next_api-merge

[billsacks]

@glemieux I'm not sure I totally understand what's going on here, so perhaps I shouldn't wade into this. But seeing the huge number of commits here makes me wonder if this was done right. I'm particularly concerned about what will happen when we go to move this branch back to master.

My understanding is that fates_next_api is currently based off of release-clm5.0, but you want it based off of master. My further understanding (maybe wrong) is that the branch in this PR accomplishes this via a merge together with a lot of conflict resolution.

However, I see:

$ git rev-list --count escomp/release-clm5.0..escomp/fates_next_api
79

i.e., there are 79 commits on fates_next_api beyond the release-clm5.0 branch, yet:

$ git rev-list --count escomp/master..glemieux/fates_next_api-release-clm5.0.30-ctsm1.0.dev093
855

i.e., there are 855 commits on the branch in this PR beyond master.

Even if the end result is correct, I'm concerned about what this might do to the history of master once this branch is brought back to master.

I would typically accomplish something like this with a rebase:

git checkout -b fates_next_api_master escomp/fates_next_api
git rebase --onto escomp/master escomp/release-clm5.0 fates_next_api_master

I'd be happy to discuss this further if it would be helpful. Also, feel free to let me know if you think I'm misunderstanding something (which is quite possible).

[glemieux]

@billsacks I don't think you're misunderstanding. This is my first try at attempting something like this so I'd be willing to scrap this for another method. Part of the reason I created the PR was to get it in front of y'all to help critique it. I've never rebased before so I'm willing to give that a shot.

[billsacks]

Okay, sounds good, thanks. I did just try doing the rebase myself, and found that (perhaps unsurprisingly) there were a number of conflicts. I didn't go far: I just spent a few minutes exploring this. A few things to note about rebases (since you say you haven't done them before):

• Git will apply commits one-by-one, from oldest to newest; it will pause whenever it hits a conflict in trying to apply the diffs from a given commit. So, in contrast to a merge, where you resolve conflicts on the whole kit and caboodle all at once, with a rebase you resolve conflicts one commit at a time (for better or for worse).

• It will drop any merge commits (and their associated log messages) from the history. If this is an issue (e.g., because there is important historical information in the merge commit messages), I've come up with workflows to maintain these merge commits, but they are more tedious.

Again, let me know if you'd like help with this - for example, we could find some time to do it together over zoom.

[glemieux]

Thanks for the quick overview. I think a zoom call would be a good idea. I sent you an email to coordinate a time to meet up.