squash merges???

[bensonr]

@FlorianDeconinck - the recent PR #37 was most likely caused by the use of squash merges. I think we need to come up with a policy on how to handle squash merges vs all commit merges. One thought I had was to only allow squash merges from user forks, but that could still cause issues if the user puts a PR against both the NASA and NOAA main branches at the same time. I prefer to use squash merges to prune out lint & fix typo style commits that are nothing more than clutter. But to keep us all in sync here, we do need to come up with some procedure to keep this from happening again.

[FlorianDeconinck]

Agreed.

Thinking about this issue, I might have come up with a way for merges to come clean, which is to always PR NOAA from NASA main and keep main in strict sync, with actual NASA code happening on a geos/main and geos/develop branch which are not synced. Squash merge down to main and PR from there should show on the NOAA side a single commit. Again, Github could react in another way.

[FlorianDeconinck]

Alright, spending a bit of time on this I have found a way to sync the repository that I think is the best way.

Basically it goes likes this.

On NASA side:

• geos/develop and geos/main are branches that are used as current working branch for NASA devs.
• main is the synchronization point with NOAA main

On NOAA side:

• main is the synchronization point with NASA.

Going forward NASA will squash-merge to NASA/main then PR upward (as in #40) to NOAA/main. Particular care will be given to the commit message since the history has been squash-merged. Especially we will reference original NASA PR and/or branches.

I'd encourage NOAA to have a develop branch as well for internal development if you want to keep a version of Pace unsync with NASA for any reasons (being the upstream repository, you don't have to).

[bensonr]

Thanks for setting up a process which works for both of us at this point in time. For now, we are going to continue to use individual forks in combo with squash merges to the NOAA-GFDL:main. If at any point the NASA and NOAA-GFDL main's would diverge or we need to bring in large swaths of development as a block, we will create a develop branch. This is approach is similar to how we've managed FMS developent.