docHub

D-057 — GitHub case-variant repos share storage on disk

Status: accepted Originally observed: 2026-06-22 Formally recorded: 2026-06-23 Decided by: Helper Mavis (session 412100071272671), based on direct API verification


Context

On 2026-06-22, Helper observed that GitHub case-variant pairs of repos (e.g., avidtech6/freshvibeui and avidtech6/FreshvibeUI) appear to share storage. Pushing a file to one instantly makes it appear in the other. They are the same repo, only the URL casing differs.

The 2026-06-22 case-variant dup cleanup incident then demonstrated the danger: deleting either casing via API deletes the underlying storage, and both URLs go 404. The "canonical keepers" (e.g., avidtech6/FreshvibeUI) were assumed distinct from the "dups" (avidtech6/freshvibeui) but the trap meant they were the same data.


Decision

  1. Case-variant repos SHARE storage on disk. This is a verified fact, not a hypothesis.
  2. Tombstoning via content (e.g., DEPRECATED README) hits BOTH casings. The case-variant trap means a content change to one propagates to the other. The "tombstone the dup with a README pointing at the canonical" pattern is impossible for case-variant dups.
  3. Deleting via API nukes the underlying storage. Both URLs go 404. The canonical is at risk if you delete the dup.
  4. The only safe cleanup is full repo deletion (which requires Administration: Delete repositories permission), done with prior verification that the underlying storage has no real content.
  5. Until cleaned up, dups are harmless IF the canonical is always linked with the canonical case. Cross-links should be case-exact.

Consequences


Pact cross-references

This is a docHub-level decision. It does not have a direct pact fragment because it concerns external system behavior (GitHub), not FVS doctrine. The lesson is captured in the dangerous/ section.


Related decisions


← back to Mavis workshop