-
-
Notifications
You must be signed in to change notification settings - Fork 89
feat(miner): freeze/snapshot mechanism for historical replay targets #3010
Copy link
Copy link
Labels
gittensor:featureGittensor-scored feature linked to a feature issue — scores a 0.25x multiplier.Gittensor-scored feature linked to a feature issue — scores a 0.25x multiplier.gittensor:priorityMaintainer-selected Gittensor priority — scores a 1.5x multiplier.Maintainer-selected Gittensor priority — scores a 1.5x multiplier.
Description
Metadata
Metadata
Assignees
Labels
gittensor:featureGittensor-scored feature linked to a feature issue — scores a 0.25x multiplier.Gittensor-scored feature linked to a feature issue — scores a 0.25x multiplier.gittensor:priorityMaintainer-selected Gittensor priority — scores a 1.5x multiplier.Maintainer-selected Gittensor priority — scores a 1.5x multiplier.
Projects
StatusShow more project fields
Done
StatusShow more project fields
Done
Context
Part of the internal historical-replay calibration harness roadmap. The harness needs a way to reconstruct exactly what a real repo looked like at a chosen past commit T, without any information from after T leaking in. The discover and analyze phases of the miner pipeline already read git history to understand a target repo's shape and recent activity; that history-reading logic is the natural starting point for a freeze/snapshot exporter rather than writing a second implementation.
Goal
Given a repo and a commit T, produce a reproducible export of the working tree and a knowable-at-T-only context bundle for use as replay input.
Requirements
Deliverables
Expected outcomes
Part of the historical-replay calibration roadmap: #2994