The recommended git tool is: git
Cloning the remote Git repository
Cloning repository https://github.com/larson-group/e3sm.git
> git init /home/jenkins/workspace/e3sm_run_gfortran_test # timeout=10
Fetching upstream changes from https://github.com/larson-group/e3sm.git
> git --version # timeout=10
> git --version # 'git version 2.34.1'
using GIT_ASKPASS to set credentials A token based key used by Jenkins to preform Github actions, created 6/21/2021
> git fetch --tags --force --progress -- https://github.com/larson-group/e3sm.git +refs/heads/*:refs/remotes/origin/* # timeout=10
> git config remote.origin.url https://github.com/larson-group/e3sm.git # timeout=10
> git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
Avoid second fetch
> git rev-parse refs/remotes/origin/clubb_silhs_devel^{commit} # timeout=10
Checking out Revision f85233ca5819e5fff7567dc3b20516c51f6f73c7 (refs/remotes/origin/clubb_silhs_devel)
> git config core.sparsecheckout # timeout=10
> git checkout -f f85233ca5819e5fff7567dc3b20516c51f6f73c7 # timeout=10
Commit message: "Autoupdated CLUBB_core Commit 3abb325943da1a557e1213b2908ead3c828aff16 Author: Gunther Huebler Date: Wed May 1 13:14:36 2024 -0500 Making num_draw_points in fill_holes a constant. We were already using this value as a constant everywhere, but passing a constant by argument list makes it difficult/impossible for a compiler to optimize using that constant, unless it does inlining. Now, rather than passing the constant num_hf_draw_points (or sometimes a hardcoded 2) we just use num_hf_draw_points directly from constants_clubb. This massively improves the performance of a loop in fill holes when using nvhpc+omp, which was the motivation for this, but should also improve the performance on CPUs. Everything is BFB."
> git rev-list --no-walk 2049ef8940dc4719e1a3e21c784eb7f2a48ffdce # timeout=10