Skip to content

24 byte-identical go-test declarations are 24 chances to fork, and one already has #12

Description

@HackingGate

Across one superproject's 39 submodules, four toolchain hooks are declared as repo: local entries and hand-copied:

  • go-test — 24 repositories
  • go-vet — 24
  • gofmt — 24
  • go-build — 22

They are byte-identical apart from one broken variant, and that variant is the argument. Two repositories declare a gofmt entry that can never exit nonzero, because gofmt -l prints the files it would reformat and exits 0 regardless. Twenty-two copies enforce; two report Passed over unformatted code. Nothing compares a copy against its siblings, so the fork was invisible until a fleet audit read all 24 side by side.

A published hook id turns 24 declarations into 24 pins. A pin can drift only in one dimension — the rev — and that dimension already has a check (no-stale-hook-pins). A copied entry: line can drift in every dimension and has no check at all.

Ask

Publish the four ids from this repository (or a companion hook repo) so adopters pin rather than transcribe. The gofmt id in particular should be written once, correctly — test -z "$(gofmt -l .)" or equivalent — rather than 24 times hopefully.

Related: #11 proposes uphold probe, which is what would have caught the broken gofmt copies at the moment they were written rather than at audit time. The two are complementary: publishing removes the chance to fork, probing catches a fork that predates the publishing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions