public realm, so GitHub users see ordinary files, commits, releases, and Actions runs while Glyph keeps the richer local model.
Mapping
| Git | Glyph |
|---|---|
| commit | publication event, checkpoint, snapshot, or imported provenance |
| branch | work context, realm, or remote tracking view |
| HEAD | current realm projection pointer or exported Git branch tip |
| working tree | materialized workspace projection |
| index | internal implementation detail |
| merge commit | publication integrating multiple work contexts |
| tag | named source graph reference or release marker |
| remote | Glyph remote origin |
Branches Become Work Contexts Or Realms
In Git, a branch is often used for two different jobs: isolating active work and naming a shared line of history. Glyph splits those jobs:- a work context isolates active work
- a realm names a permissioned source view
Commits Become Snapshots, Checkpoints, Or Publications
Git commits are overloaded. They can mean “I saved progress”, “this is ready for review”, “this is public”, or “CI needed a point in history.” Glyph separates those meanings:- snapshot: captured source state
- checkpoint: explicit milestone inside work
- publication: intentional movement into a realm
Export
The current prototype exports thepublic realm to a clean Git repository and can push that export to GitHub.
.gitignore and .gitinclude files come from glyph.yaml defaults.
GitHub Is Infrastructure
When Glyph pushes to GitHub, it is publishing a compatibility projection. The canonical source graph remains local in.glyph/ for prototype 0.
This lets a project use GitHub for visibility, hosting, CI, and releases while still using a source-control model designed for agents.
Git’s weak spot here is not that it lacks power. It is that power comes from conventions layered on top: branch naming, commit discipline, protected branches, PR rules, and CI rituals. Glyph keeps the useful boundary output, then gives the inner workflow explicit concepts for work, visibility, and publication.