1. Overview
Distributed version control with user-held history, inspectable changes and local repository recovery; the assessed configuration and external dependencies are stated below.
Category: VCS & Core.
2. Version and scope assessed
Version assessed: Git 2.54.0.windows.1; configured local vcs_core workflow, rating reconciliation batch 1.
3. Overall determination
Computing determination
4. Principle profile
| Order | Principle | Finding |
|---|---|---|
| I | Sovereignty | ✓ Meets |
| II | Longevity | ✓ Meets |
| III | Locality | ✓ Meets |
| IV | Transparency and Control | ◐ Partially meets |
5. Fundamental requirements
| Requirement | Status |
|---|---|
| E1 Independent access to essential information | ✓ Pass |
| E2 Practicable exit and migration | ✓ Pass |
| E3 Independent interpretation and recovery | ✓ Pass |
| E4 Continuing authority and custody over already-created work | ✓ Pass |
| E5 Governability of consequential actions | ✓ Pass |
6. Evidence and verification
- E1: Git repositories store history locally and can be cloned, copied, bundled, or mirrored without a central service. (source), confidence medium
- E2: Git supports local and remote clones, bundles, and exports, though hosting-specific issues, pull requests, and CI metadata are outside the repository. (source), confidence medium
- E3: In an isolated Git 2.54.0.windows.1 fixture, a full --all bundle mirrored all recorded branch/tag/stash refs with matching object IDs and passed fsck. Ordinary clone omitted refs/stash, repository-local configuration, the marker hook and submodule working-tree contents; these need separate recovery planning. (source), confidence medium
- E4: Branching, diffing, merging, and history inspection work offline on local repositories. (source), confidence medium
- E5: The full bundle verified in an empty repository, whereas an incremental v1..main bundle failed verification for missing prerequisite commits. Successful bundle creation therefore does not establish a self-contained backup. (source), confidence medium
- sovereignty: Git gives users direct custody of complete repository history and multiple exit paths. (source), confidence medium
- longevity: For the configured vcs_core fixture, complete preserved history/configuration/submodule material reconstructed a usable repository without the original paths. This supports Longevity for that workflow; it does not certify LFS, signed provenance, arbitrary automation or future-version recovery. (source), confidence high
- locality: Core version-control operations are deliberately local and offline-capable. (source), confidence medium
- transparency: E5's minimum is demonstrated for the declared local commands: changes are inspectable and committed-history reset is correctable. Reflog retention is finite, untracked deletion needs an external backup, and executable hooks/remote automation were excluded rather than verified. These residual limits justify Partially meets, not a blanket Meets. (source), confidence high
- E3: The configured local vcs_core backup restores all refs, author/committer timestamps and identities, tracked bytes, ignore rules, separately preserved local configuration and one submodule after the original paths become unavailable; fsck succeeds. Full main/submodule bundles plus configuration are required, not the displayed main bundle command alone. This Pass excludes LFS, executable hooks, signature authenticity and hosted-service state; the earlier broader candidate scenario remains open. (source), confidence high
- E5: In the declared local configuration, diffs expose the history reset, reflog retains the displaced committed tip and explicit reset restores it. clean -n lists and retains a disposable untracked file; clean -f explicitly removes it and reports removal. That file is restored from a separate copy, not Git history. This demonstrates proportionate command authorization, inspection and available correction for these operations, not automatic recovery of arbitrary uncommitted work. (source), confidence high
7. Migration and recovery
Native storage format: Content-Addressable Merkle DAG (.git).
Synchronization or runtime model: Decentralized SSH / HTTPS push-pull.
Example export or inspection command (not verified against any particular version or data set): git bundle create repo.bundle --all
8. Architectural strengths
Established strengths and their scope are recorded in the evidence and assessment findings on this page.
9. Architectural limitations
- Passes apply only to the predeclared installed local-core configuration, not every Git deployment.
- A full bundle alone omits local configuration and submodule payloads; preserve these separately.
- Untracked clean deletion has no Git-history undo; external backup was required in the test.
10. Assessment findings and remaining work
Verification scenario: Bundle and clone all branches and tags; include LFS and submodules; simulate loss of the hosting account.
What may invalidate an overconfident claim: Full Git history is portable; LFS objects, submodule remotes, and external issue trackers may not be.
Earlier candidate protocol (not an executed result): The broader proposal included LFS, air-gapped transfer and two assessors. Those aspects are still unverified. The current local-core assessment is separately declared before its checks in evidence/rating-reconciliation/batch-1/plan.json.
Documentation starting point: https://git-scm.com/docs/git-bundle
Evidence update: 23 October 2026
- Resolved: In an isolated Git 2.54.0.windows.1 fixture, a full –all bundle mirrored all recorded branch/tag/stash refs with matching object IDs and passed fsck. Ordinary clone omitted refs/stash, repository-local configuration, the marker hook and submodule working-tree contents; these need separate recovery planning. Source.
- Resolved: The full bundle verified in an empty repository, whereas an incremental v1..main bundle failed verification for missing prerequisite commits. Successful bundle creation therefore does not establish a self-contained backup. Source.
- Open: LFS payloads, signed-tag authenticity, executable hooks, remote/hosted permissions, corruption/crash recovery, independent network isolation, older versions and the earlier broader two-assessor candidate protocol remain unverified.
Assessment follow-up: E3/E5 and their associated principle findings are now reconciled in rating batch 1 below. Earlier source/fixture observations remain valid within their stated scope; they are not themselves blanket Pass decisions.
Rating reconciliation: 23 October 2026
Scope: Git 2.54.0.windows.1; configured local vcs_core workflow, rating reconciliation batch 1 Individual-custodian perspective. The local vcs_core configuration and departures were declared before the new checks; the original broader scenario is not claimed complete.
| Criterion | Current finding |
|---|---|
| E3 Independent interpretation and recovery | Pass |
| E5 Governability of consequential actions | Pass |
| Longevity | Meets |
| Transparency and Control | Partially meets |
E3: The configured local vcs_core backup restores all refs, author/committer timestamps and identities, tracked bytes, ignore rules, separately preserved local configuration and one submodule after the original paths become unavailable; fsck succeeds. Full main/submodule bundles plus configuration are required, not the displayed main bundle command alone. This Pass excludes LFS, executable hooks, signature authenticity and hosted-service state; the earlier broader candidate scenario remains open.
E5: In the declared local configuration, diffs expose the history reset, reflog retains the displaced committed tip and explicit reset restores it. clean -n lists and retains a disposable untracked file; clean -f explicitly removes it and reports removal. That file is restored from a separate copy, not Git history. This demonstrates proportionate command authorization, inspection and available correction for these operations, not automatic recovery of arbitrary uncommitted work.
longevity: For the configured vcs_core fixture, complete preserved history/configuration/submodule material reconstructed a usable repository without the original paths. This supports Longevity for that workflow; it does not certify LFS, signed provenance, arbitrary automation or future-version recovery.
transparency: E5’s minimum is demonstrated for the declared local commands: changes are inspectable and committed-history reset is correctable. Reflog retention is finite, untracked deletion needs an external backup, and executable hooks/remote automation were excluded rather than verified. These residual limits justify Partially meets, not a blanket Meets.
Evidence record: evidence/rating-reconciliation/batch-1/README.md and runtime-results.json. No target software was installed. The new checks used existing runtimes in disposable directories, not a second machine or an independently implemented engine.
Remaining work: LFS payloads, signed-tag authenticity, executable hooks, remote/hosted permissions, corruption/crash recovery, independent network isolation, older versions and the earlier broader two-assessor candidate protocol remain unverified.
Contribute verification evidence for Git
Have you tested clean-machine restoration, format migration, or failure rollback for Git? We welcome reproducible laboratory logs, synthetic test fixtures, and independent assessments to resolve open findings.
Read the evaluation protocol · Submit verification records on GitHub
Rating reconciliation batch 1: E3 Pass; E5 Pass. Longevity Meets; Transparency and Control Partially meets. See the declared scope and reasons below; earlier bounded evidence findings remain recorded. The assessment procedure is described in the methodology.