Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additions/deletions of an externals submodules can lead to a modified status after running checkout_externals #157

Open
billsacks opened this issue Apr 13, 2021 · 0 comments
Labels

Comments

@billsacks
Copy link
Member

Summary of Issue:

In some situations, changing the version of an external that has submodules and then running checkout_externals can result in that external having a modified (M) status. This prevents subsequent runs of checkout_externals unless you remove the offending external or do something to bring it back into sync. I can't tell whether the offending external is actually in a modified state or if manage_externals just thinks it is.

For the reproducer below (changing between ctsm5.1.dev029 and ctsm5.1.dev030), @gold2718 's hypothesis about the cause is:

The CDEPS hash in 029 has one submodule, fox.
The CDEPS hash in 030 has two submodules, fox and genf90

When you checkout the externals in 029, manage_externals initializes the submodules in CDEPS.
When you checkout the externals in 030, manage_externals does NOT initialize the submodules in CDEPS because it thinks they are already initialized. This leaves genf90 (the new submodule) as not initialized.

I believe that if you tried this sequence where new submodules are not introduced, there will not be a problem.

To avoid removing cdeps, you can:
cd cdeps
git submodule init
git submodule update
cd ..

For what it's worth, I think I have also run into this problem going the other way (from dev030 to dev029, resulting in a deletion of one of CDEPS's externals).

Expected behavior and actual behavior:

Expected behavior: after running checkout_externals, no externals should be in a modified state.

Actual behavior: in some situations, after running checkout_externals, externals with submodules can be in a modified state.

Steps to reproduce the problem (should include model description file(s) or link to public repository):

git clone [email protected]:ESCOMP/CTSM.git
cd CTSM
git checkout ctsm5.1.dev029
./manage_externals/checkout_externals cdeps
git checkout ctsm5.1.dev030
./manage_externals/checkout_externals cdeps
./manage_externals/checkout_externals -S cdeps

gives:

 M  ./components/cdeps
    ./components/cdeps/fox
    ./components/cdeps/share/genf90

What is the changeset ID of the code, and the machine you are using:

The above CTSM version is using manage_externals at 39ad532.

have you modified the code? If so, it must be committed and available for testing:

No

Screen output or log file showing the error message and context:

See above reproducer

@billsacks billsacks added the bug label Apr 13, 2021
billsacks added a commit to billsacks/manage_externals that referenced this issue Apr 13, 2021
Inspired by ESMCI#157 and how
I've been working around it.
billsacks added a commit that referenced this issue Apr 21, 2021
Add another option for when an external is in a modified state

Add another option for when an external is in a modified state

Inspired by #157 and how I've been working around it.

User interface changes?: No

Fixes: None

Testing:
test removed: none
unit tests: pass
system tests: pass
manual testing: examined output
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant