Handling of cime submodule for cprnc

[ekluzek]

The cime submodule .gitmodules for cime6.0.246 doesn't have fxtag in it and as such results in a couple of things that are awkward. Namely that if I blow away the cime directory and contents it's difficult to get it back to normal.

First is warns that there is no "fxtag" for cprnc in cime's .gitmodules. I think this is because the intent is to get the latest on master for cprnc in cime.

\rm -rf cime
./bin/git-fleximod update cime
Recursively checking out submodules of cime

e    CIME/non_py/cprnc has no fxtag defined in .gitmodules

                cime up to date.

And then cime is identified as modified with git status and cprnc is identified as modified inside of cime

git status
On branch update_gitfleximod
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
    modified:   cime (modified content)

cd cime
git status
HEAD detached at 422ddaa77
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
    modified:   CIME/non_py/cprnc (modified content)

no changes added to commit (use "git add" and/or "git commit -a")

I've tried various things to then restore it, but the only thing that works for me is:

cd cime
\rm -rf  CIME/non_py/cprnc/
[erik@izumi cime]$ git submodule update --init --checkout --recursive
Submodule path 'CIME/non_py/cprnc': checked out '9276b219750881633d8673c72ec80ac821f96d82

[ekluzek]

I suspect what happens is that git-fleximod doesn't handle cime's cprnc submodule because of the missing fxtag. If that's the case I wonder about a couple possibilities:

1.) Have git-fleximod still handle a submodule without a fxtag (just give a warning about it) 2.) Have git-fleximod refuse to handle a .gitmodule submodule without fxtag and abort with an error (this would require a change in cime) 3.) Have git-fleximod give a warning about the submodule and tell the user how to handle it

Those are the ideas I have...

[jedwards4b]

Of your list 1 is the intended action. Perhaps the warning is not clear? I think I have also determined that there is a problem in recursion in the 0.7.6 version that I am working on and will have a fix soon.

[ekluzek]

Ahh, good to know. I think maybe the recursion issue leads to the problem I see when I blow away cime. It obviously works correctly in other contexts and I don't know why there would be an issue in this case. So I'll try this again when you bring that fix in.

Anyway, the issue on the warning is that I as a user may not understand it's significance. Perhaps adding a line that says something like

"Handling by checking out the latest version on the default branch for this submodule"

That way I am told what git-fleximod is trying to do. Without it I wondered if this case, just wasn't handled by git-fleximod.

How does that sound for an addition line for the warning @jedwards4b?

[ekluzek]

This now works for me when I update to v0.7.7. It also gives a message about recursively checking everything out under a given submodule, so I think the messaging is good now as well.

So closing.

[ekluzek]

Fixed with #43 v0.7.7