chore: Pinning submodules to commit SHA

[ChaosEternal]

Fixes #1083

What does this PR do?

Pinning the submodules to their commit SHA

Type of Change

• Bug fix (non-breaking change)
• New feature (non-breaking change)
• Breaking change (fix or feature with breaking changes)
• Documentation update

Test Plan

• Unit tests added/updated
• Integration tests added/updated
• Passed make installcheck
• Passed make -C src/test installcheck-cbdb-parallel

Impact

Checklist

• Followed contribution guide
• Added/updated documentation
• Reviewed code for security implications
• Requested review from cloudberry committers

Additional Context

CI Skip Instructions

---

[github-actions]

Hi, @ChaosEternal welcome!🎊 Thanks for taking the effort to make our project better! 🙌 Keep making such awesome contributions!

[edespino]

Thanks for outlining the plan and rationale — pinning submodules to a specific commit SHA is definitely a step forward for ensuring reproducibility.

That said, since several of the submodules appear to reference well-established upstream projects (e.g., googletest, benchmark, tabulate), it's worth considering tag-based pinning instead of raw commit SHAs where possible. Git submodules can reference a tag — essentially, you'd checkout the desired tag in the submodule and commit that state in the superproject. This approach has a few advantages:

• Improved traceability: Tags often correspond to stable releases (e.g., v1.14.0), which makes it easier to understand what version is being used at a glance.
• Community alignment: Staying in sync with upstream’s versioning helps when debugging or contributing upstream.
• Reduced churn: Upstream tags are less likely to be force-pushed or removed compared to commits on active branches.

Here’s how you might do it:

cd submodule-dir
git fetch --tags
git checkout tags/v1.14.0
cd ../
git add submodule-dir
git commit -m "Update submodule to tag v1.14.0"

This doesn’t prevent you from switching to a subtree model later, which has its own merits, especially for long-term archival or if upstream becomes unstable or disappears. But in the meantime, where upstream uses semver-style tagging, tagging improves clarity and slightly reduces maintenance overhead compared to opaque SHAs.

Happy to help explore this option further if there’s interest.

[tuhaihe]

Hi, is there any update on this PR? We're nearing the release, but there hasn't been any recent developments. We need to make progress.

If we can't reach a consensus at this time, we can postpone this PR from the 2.0.0 release.