ExternalProject: New keywords that specify the git tag/branch/hash more explicitly than GIT_TAG
Split out from #22742 (comment 1083528) as a dedicated issue so it can be better tracked.
...[I have some reservations about] trying to change the meaning or behavior of GIT_TAG
. Even with a policy, this has the potential to be really disruptive. Instead, I'm wondering if we can introduce a set of new keywords that would be mutually exclusive with GIT_TAG
, something along the lines of:
GIT_REF_TAG
GIT_REF_BRANCH
GIT_REF_COMMIT
If any of these are given, GIT_TAG
must not also be specified.
As per @sean.middleditch's suggestion [in #22742], we could allow GIT_REF_COMMIT
to be given with GIT_REF_TAG
, although probably not with GIT_REF_BRANCH
. This would allow for more efficient checking of whether a fetch is needed (you can immediately confirm whether you have the specified commit), as well as providing the robustness benefit of confirming that the requested tag is for the specified commit. The new keywords would also allow the implementation to confirm whether the ref requested is of the specified type (i.e. expecting a tag, but getting a branch instead could be caught as an error).
Also see the discussion about shallow clones and branches, starting at #17770 (comment 380957). This would probably need to be considered as part of such a change.
It's an open question whether we deprecate GIT_TAG
at the same time with a policy, issuing a warning prompting the developer to update the project to use the new GIT_REF_...
keywords instead. That could be really noisy, but then again, the performance and robustness gains might be worth it.