Updated files for creating CESM cases under git(hub) control

[kdraeder]

The previous instructions applied to putting existing cases under git(hub) control. These additions describe how to create a controlled CESM case in a way that keeps cases separate for cleanly working with multiple cases simultaneously.

[hkershaw-brown]

Hi @kdraeder what level of review are you looking for here? Do you want this readme to be used by other people (dart team, general cesm-dart users)? Is this readme notes for your own future use?

Cheers, Helen

[kdraeder]

The kind of review depends on who you think the right audience is. I'll definitely refer to it for my own work. It will be useful to the team if or when they need to deal with what I leave behind. I wrote it with general cesm-dart users in mind, who don't already have a way to archive their experiment setups. If it looks useful for that, there should be a link to it somewhere, so that they can find it.

[kdraeder]

Thanks for pointing out git init. I don't remember seeing that before.
This may turn into git tutorial for me . . .

One question that may determine the answers to a lot of others is whether there should be an archive of experiments that are of interest to multiple people in DAReS (and ...?) and will be maintained independently of who's in DAReS.
If so, then I think it's helpful to have a standardized workflow spelled out. If not, then we'll each archive the way we like and other people can figure it out later, if needed.

You started a thought with "I'm not sure if", which I'm guessing ends with something like "anyone else will want to do it this way". Entirely possible, and helpful to know, if you think that's the case.

So far it looks to me like git init would replace just my git checkout -b $CASE, but without naming the branch. So the rest of the steps might still be useful. If a bunch of experiments will be pushed to the same repository, I feel like they should be kept separate.
It's not clear how separate is enough.
Would it be good to have each in a separate directory but all be parts of the main branch? My impression of that is that each new branch from main would then have all existing experiments in it. I guess init would avoid that by making an empty branch, which can be named later. ?

Good point about enforcing the branch names. I'll look into that if the strategy I've proposed survives the review.

If this seems like it could be useful to anyone but me, I'll clarify the confusing parts. Otherwise, I'll mostly leave it as is and we can wrap this up.

Thanks for working through it.

[hkershaw-brown]

I think my brain was farting when I made the comment, there are two sentences that just tail off.

The init would be for a new repo for each case. So ignore that if you are using a branch for each case, you have it correct for the branch for each case.

I think the thing I would be worried about would be multiple people using (or deleting the same branch). So long as people are aware of that when they make use of this CASES repo.

[kdraeder]

To add a bit more to my tutorial; does 'a new repo for each case' mean only a local repo, which can have the same 'origin' as other local repos, or does it also mean a new repo on github?

I'll work on the protection for branches, and answer your other questions.

[hkershaw-brown]

new repo for each case, github and local. But ignore that for your method which is this one repo, with a branch for each case

[kdraeder]

I think if other people are going to use (commit to) DART_CASEs then you'll need some way to enforce unique names for the branches, or protect the branches.

I dug into the old style branch protection and the newer "rule sets" and eventually found what I think I want in the branch protection (but not in rule sets):

Optionally, enable branch restrictions.
         Select Restrict who can push to matching branches.
         Optionally, to also restrict the creation of matching branches

But, of course, that option is not offered in the form that defines a new branch rule. I sent a query about it through the github complaints button at the bottom of the branch protection page.