Import and export trees
Bring source in from GitHub, GitLab, and internal remotes, then export selected trees back out when external compatibility matters.
Monorepo-native neo-forge
A monorepo for you
TinyTree is a neo-forge: a hosted source-control service, API, and custom client for teams that want one durable monorepo, focused views over that tree, and explicit import/export workflows instead of repository sprawl.
Git-compatible entryCentral neo-forgeCLI and API surface
$ tt view
aa platform/ci narrowed clone 182 commits
br agents/review lazy history 3 changes
$ tt checkout aa
entered platform/ci
$ tt change send
CR-142 opened
Patch Setland in order
- CR-142readyImport buildkite treeCI: 6 checks passing
- CR-143reviewWire Starlark hookCI: starlark-check running
- CR-144draftExport CI viewCI: waiting for CR-143
Tiny trees
A monorepo is made up of many tiny trees.
TinyTree keeps one durable source tree while giving every imported project, service, package, generated source tree, and team workspace a native place inside it.
Craft dedicated views
Expose only the subset of files and directories a team, agent, workflow, or external mirror needs.
Review code and patch sets
Keep traditional SCM workflows such as code review, patch set review, history, and ownership in the same product surface.
Automate tree boundaries
Attach hooks, CI/CD, policy checks, and export jobs to the whole monorepo or to the tiny trees inside it.
Trees all the way down
What if your repo config is a tree?
.tinytree/config/
A monorepo-native forge can rethink objects that usually live outside source control. Repo config, releases, dependencies, policy, and automation can become ordinary files and directories, tracked and reviewed with the rest of the tree.
Developer workflow
Source control primitives you can operate.
TinyTree should be understandable from the CLI, scriptable through an API, and visible in the hosted forge. The same concepts should work for people, CI systems, and coding agents.
Mirror trees into one source graph
Bring GitHub, GitLab, and internal remotes into one canonical monorepo without losing their boundaries.
Work inside narrowed clones
Discover view definitions, create focused worktrees, and share one lazy local object cache across them.
Send reviewable changes
Submit one Change Request or an ordered Patch Set to the forge without making branch names the workflow.
The model
Native tooling for every tree boundary.
TinyTree starts as a Git-compatible neo-forge with a hosted server and client wrapper around Git. It evolves toward a centralized-leaning SCM where imports, exports, views, reviews, hooks, and CI are native source-tree concepts.
01
One canonical monorepo remains the durable home for source, history, policy, and automation.
02
Tiny trees model projects, services, generated code, vendored dependencies, and external mirrors inside it.
03
Views create focused workspaces without pretending those workspaces are separate repositories.
04
Hooks and CI/CD run against explicit tree boundaries, not ad hoc repository glue.
05
Narrowed clone is built into the workflow, so users and agents can work with focused views, short relevant history, and lazy downloads.
06
Starlark configuration replaces YAML for programmable imports, exports, hooks, views, and policy.
07
Fine-grained access control applies to different views of the monorepo instead of only the whole repository.
Roadmap
Start Git-compatible. Grow new SCM foundations.
Storage
Store the world
Design a new storage backend for keeping very large, many-origin source trees inside one monorepo.
Changes
Track intent
Use Change-IDs as stable review units across patch sets, rebases, imports, and exports.
Evolution
Record rebases
Model history rewriting with an Evolve-style data model inspired by Mercurial, rather than treating rebases as invisible events.