Import and export trees
Bring source in from GitHub, GitLab, and internal remotes, then export selected trees back out when external compatibility matters.
New generation source forge for monorepo

$ 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
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.
Bring source in from GitHub, GitLab, and internal remotes, then export selected trees back out when external compatibility matters.
Expose only the subset of files and directories a team, agent, workflow, or external mirror needs.
Keep traditional SCM workflows such as code review, patch set review, history, and ownership in the same product surface.
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
.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
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.
Bring GitHub, GitLab, and internal remotes into one canonical monorepo without losing their boundaries.
Discover view definitions, create focused worktrees, and share one lazy local object cache across them.
Submit one Change Request or an ordered Patch Set to the forge without making branch names the workflow.
The model
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.
One canonical monorepo remains the durable home for source, history, policy, and automation.
Tiny trees model projects, services, generated code, vendored dependencies, and external mirrors inside it.
Views, narrowed clone, and access control create focused workspaces with short relevant history, lazy downloads, and policy attached to the right slice of the monorepo.
Hooks and CI/CD run against explicit tree boundaries, not ad hoc repository glue.
Starlark configuration replaces YAML for programmable imports, exports, hooks, views, and policy.
Roadmap
Design a new storage backend for keeping very large, many-origin source trees inside one monorepo.
Use Change-IDs as stable review units across patch sets, rebases, imports, and exports.
Model history rewriting with an Evolve-style data model inspired by Mercurial, rather than treating rebases as invisible events.