COMP: Pin proxTV to an immutable overlay tag

[hjmjohnson]

proxTV_GIT_TAG named the anchor branch for/itk-proxtv-3.3.0-69062fe5, so advancing that branch changed what ITK builds without any change landing here. Pin the immutable tag for/itk-proxtv-3.3.0-69062fe5-r1 instead, which resolves to the same overlay tip and cannot move.

Overlay r1 also brings in the GCC warning cleanup merged as InsightSoftwareConsortium/proxTV#1.

What overlay r1 contains

Three commits on the ITK proxTV overlay, all compiler-warning fixes in the vendored C sources:

• 34af3b0 — guard #pragma omp behind #ifdef _OPENMP and the MSVC warning(suppress:) pragmas behind #ifdef _MSC_VER
• f726e32 — size_t loop counters where compared against size_t bounds (-Wsign-compare), and a -Wmisleading-indentation fix
• 0903e7c — reject n < 2 in more_TV2/morePG_TV2 and npen < 1 in PD_TV/PDR_TV before those values reach memcpy/calloc size arguments (-Wstringop-overflow, -Walloc-size-larger-than)

Upstream base is unchanged: albarji/proxTV 3.3.0, commit 69062fe5. The overlay is a fast-forward, 4c53ae7 → 0903e7c.

The same fixes were offered upstream as albarji/proxTV#63, but upstream has merged nothing since 2018, so the overlay remains the source of truth.

Why a tag, and why this tag name

Documentation/Maintenance/ThirdPartyForkConventions.md notes that DCMTK "pins an immutable commit," and warns that a ref existing as both a branch and a tag under the same name is ambiguous. Pinning a branch name has the opposite failure: the pin is unambiguous but not stable, so a push to the fork silently changes ITK's build.

The tag name therefore keeps the for/ prefix used by the other fork tags (for/itk-20260430-fef1460e in eigen, for/itk-vxl-master-8d91974 in vxl) and adds an -rN suffix so it cannot collide with the anchor branch. The suffix is needed because the convention's name encodes only the upstream version and base SHA — both unchanged here — so successive overlay revisions on the same upstream base are otherwise indistinguishable.

The anchor branch for/itk-proxtv-3.3.0-69062fe5 still exists and still points at 0903e7c; it remains the update target per the fork's welcome procedure. Only ITK's pin moves to the immutable ref.

Verification

• git clone --branch for/itk-proxtv-3.3.0-69062fe5-r1 (full clone, matching FetchContent_Declare — the proxTV module sets no GIT_SHALLOW) checks out 0903e7c, with the pragma guards and size validation present in the tree.
• The tag is annotated and advertises both the tag object and the peeled ^{} commit.
• clone --branch against an annotated tag prints warning: … is not a commit!; this is pre-existing behaviour shared with eigen's for/itk-20260430-fef1460e tag and does not affect the resulting checkout.

CI on this PR is the end-to-end test: it exercises the fetch at the new tag on every platform that builds ITKTotalVariation.

[blowekamp]

I think the "for/itk-XXXX" convention is used in most of our forks and they have similar issues. Human though should be used to update the procedures and documentation as needed to change the convention.

[hjmjohnson]

I think the "for/itk-XXXX" convention is used in most of our forks and they have similar issues. Human though should be used to update the procedures and documentation as needed to change the convention.

@blowekamp. I want to understand your comment on this draft PR. Are you advocating for the proposed "-r1" extention to be documented on the welcome branch documentation on all the itk forks? This draft was intended to spark a discussion, but I did not expect such quick response to the "adds an -rN suffix so it cannot collide with the anchor branch".

I won't have time to do that across all the itk forks, but I'll make a tracking issue to get around to it sometime this fall.

[blowekamp]

Sorry for the short response. I don’t have much time right now either, but I wanted to short cut another convention being introduced without discussion and documentation.

Perhaps for “live” references the actual hash should be used and a comment with the branch name is appropriate.

The clones during a build would be live references This is different than the scripts for third party which only use the reference once so the branch name works and no hash needed.

[hjmjohnson]

We are all too busy right now :(. Thanks for your response. I'll be on vacation until August 18th, but will try to squeeze in a "live" reference update during downtime.