README.adoc
git-ents
An (in-development) experimental forge with all metadata stored as Git objects.
Vision
Git is far more flexible than existing forges assume.
Large files can be fetched lazily via partial cloning and promisor remotes.
New libraries, e.g. Gitoxide, can provide atomic updates across multiple refs.
Reflection in modern programming languages, such as facet, allows for more general object storage, diffing, and merging with a single procedural macro.
We believe that these recent advances have removed the last remaining roadblocks to a technical end that many have tried and failed to reach before: project data stored directly in verifiable Git objects.
New porcelains around Git, and new extensions to the git CLI, are cheap to write.
This is evident from the numerous git command extensions available today.
By encoding all project metadata as Git objects, and by providing new tools for encoding data of arbitrary shapes as Git objects, this robust ecosystem of developer tools can extend into project metadata tools.
Values
In a 2017 Node Summit talk, Platform as a Reflection of Values, the following table of values is presented by Bryan Cantrill. He notes that these values are often in tension with one another, and engineering projects must prioritize some over others. In the interest of transparency (one of this project’s core values) the values this project deliberately prioritizes over all others are discussed immediately below.
Approachability |
Interoperability |
Robustness |
Availability |
Maintainability |
Safety |
Compatibility |
Measurability |
Security |
Composability |
Operability |
Simplicity |
Debuggability |
Performance |
Stability |
Expressiveness |
Portability |
Thoroughness |
Extensibility |
Resiliency |
Transparency |
Integrity |
Rigor |
Velocity |
Simplicity
This project aspires to be simple. All project metadata – issues, reviews, contributors, repository configurations, releases, etc. – are stored in one database: Git’s at-rest data model. Of course, we will not force the usage of a data model that fundamentally cannot represent modern software projects. If we determine the core thesis of this project is false, we will reevaluate. As stated above, this project is experimental!
Extensibility
With all project metadata stored in one data model, there’s no reason why projects should be limited by legacy data categories. Multiple issue assignees? Approvals issued for part of a pull request? Reviews entirely outside of pull requests? As long as you bring your own schema, we will happily help to track any data that’s useful for your project.
Portability
Your data is yours, and you will never be locked in by platform-specific data formats.
Want to move to another forge?
All of your data is one (correctly configured) git fetch away.
Our open-source platform and accompanying developer tools will allow you to move your project with ease.
Transparency
We’ve all experienced the frustration of platforms changing their policies without warning. Worse: too many of us have had to debug failing workflows, only to discover subtle misbehaviors that have no accompanying documentation. In this project, as much software as possible will be freely available under permissive open-source licenses. Decisions in the development and governance of this project will default to being publicly available, with community input solicited explicitly whenever possible.
Usage
More documentation is en route!