You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
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
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 ofcheckout_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:
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):
gives:
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
The text was updated successfully, but these errors were encountered: