-
Notifications
You must be signed in to change notification settings - Fork 131
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
[meta/GitHub workflow] A warning about CICE PRs that update Icepack #753
Comments
@phil-blain, thanks for raising this issue. From what I remember, when I merged PR #733, I noticed that Icepack was NOT correct. But my plan was to update Icepack on main right after that which is what I did. Had I not done that, I would have mentioned that the Icepack changes should be removed from PR #733. But I figured the version of CICE with a non-conformant Icepack would not be on the head for any duration and that it would not have any impact. Maybe that was wrong. The formal update to Icepack on main after PR #733 did bring in the same changes (I think) that are with #733. Of coarse, the history is different. Just to clarify,
In the bigger picture, I agree we should be more careful about not bringing in Icepack changes to CICE when we don't want them. In particular, if you have changes to Icepack and do "git commit -a", you are likely to add the Icepack changes to the CICE commit even if you don't intend to. When I do git status and I see "icepack" as changed, I then never do "git commit -a" and do "git add" for specifically just the files I want to add. |
Yes, the next commit, c6470cf (Update icepack to 3cb1746a202615044e (#743), 2022-07-31), updates Icepack:
and Icepack PR 393 (CICE-Consortium/Icepack#393) is the one that merged the four Icepack commits mentioned above.
Yes, it is fine since c6470cf.
If ever GitHub decides to start running
This pushes a ref named In general, I think that never using |
Maybe a good follow-up action to this would be to update our CICE PR template and add a question like:
|
I don't think having access to CICE 9be1c35 is important. For the sake of robustness, maybe we should push Icepack 595c00cfe, although I'm not that concerned. One of the problems is that sometimes folks don't realize they are committing an update to Icepack, so having a questions on the PR template might not help :). You really don't see the changes except as a list of files in the PR, so it's easy to miss, especially as submodules tend to be a bit confusing. |
In my opinion it is really, really important for all commits on CICE's
Well, the Icepack changes are listed in the "Files" tab of the PR, so if we point them there, it's easy to see if Icepack was changed or not, I would say. It won't be listed at all if it was not changed. |
OK, this should now exist,
Thanks for the guidance @phil-blain. I will also update the CICE PR template. |
I checked if other older CICE commits also reference Icepack commits not found on Icepack's I've pushed references for all those CICE commits to my Icepack fork, similar to what I suggested above for 9be1c35. So we might want to also push these refs over to CICE-Consortium/Icepack. This should do it: # clone my fork
git clone https://github.com/phil-blain/Icepack icepack
cd icepack
# fetch the cice/* refs
git fetch origin 'refs/cice/*:refs/cice/*'
# push them upstream
git remote add upstream https://github.com/cice-consortium/Icepack
git push upstream 'refs/cice/*:refs/cice/*' |
Thanks @phil-blain, I executed the commands above and it seems to have worked. Feel free to confirm that there aren't any missing references in CICE anymore. Hopefully that's true and we avoid this issue in the future. Thanks again! |
Thanks @apcraig. I confirmed the Just to confirm: the missing references are still in CICE; changing that would involving changing all commit hashes (in CICE and Icepack!) which we do not want. The If we want to checkout an earlier CICE commit, and this commit references an Icepack commit not on I'll close. thanks again. |
Hi everyone,
I noticed that a recent CICE PR (#733) was merged with a change to Icepack that references a commit that is not present on the
main
branch of Icepack.We can see this on a fresh clone of CICE:
Notice "(commits not present)" on the last line. If we
cd
into Icepack, we indeed are missing the new commit introduced by this PR:$ cd icepack $ git show 595c00cfe8121d4e2405282fa08c0907b22e8718 fatal: bad object 595c00cfe8121d4e2405282fa08c0907b22e8718
If we take a look at the icepack changes in PR 733, and click on the "25 files" link, we are taken to this page: CICE-Consortium/Icepack@76ecd41...595c00c which shows the Icepack commits
in the range 76ecd41...595c00c, i.e. the new Icepack commits introduced in the PR. We notice that these commits are authored and commited by @dabail10 , which means that they are not on the
main
branch because all commits on themain
branch are squash merges and are committed by the person that merges the PR tomain
. If we click on the hash for each of the 4 commits, GitHub shows:These four commits indeed originate in Dave's fork of Icepack, though the branch on which they were created is not on GitHub anymore, since we see the same message on his fork, see for example:
dabail10/Icepack@595c00c.
The CICE PR should not have been merged with an Icepack commit not present on Icepack's
main
branch, in my opinion. I missed it when I reviewed the PR.This is a little bit concerning, because it means it is hard to checkout this earlier version of CICE and compile it:
git checkout --recurse-submodules 9be1c35ae62199ae0ea9c4f339105c7aec3192bf fatal: failed to unpack tree object 595c00cfe8121d4e2405282fa08c0907b22e8718 error: Submodule 'icepack' could not be updated. error: Cannot update submodule: icepack Aborting
It is not impossible though, because the commit is still present on GitHub, so if we fetch it directly by its hash it succeeds:
Note that we can fetch it from CICE-Consortium/Icepack (and not necessarily dabail10/Icepack) because of the fact that GitHub uses the Git alternates mechanism to store all objects of all forks in the root repository of a fork network, which I've mentioned before.
There is virtually no risk that this commit becomes unavailable even if no branch points to it or its children, because it's known (a quick Google search will confirm it) that GitHub never runs
git gc
in their repositories and thus all commits are kept indefinitely.So I'm just opening this issue as a warning for everyone to be more careful when merging CICE PR that update Icepack.
Additionnaly it shows how to get fetch a specific commit by its hash if ever someone needs to compile CICE at 9be1c35.
The text was updated successfully, but these errors were encountered: