Early answers.

TinyTree is a neo-forge: a hosted source-control service, API, and custom local client built around one large source tree. It starts with Git-compatible hosting and a TinyTree client wrapped around Git.

Over time, TinyTree intends to add features that outgrow Git and traditional VCS alternatives. The client should make local work feel focused and fast, while the server provides the authoritative forge for review, code search, blame and praise, access policy, imports, exports, and view state.

TinyTree leans toward centralized version control. Some features, including code search, blame and praise, review state, access policy, imports, exports, and view discovery, work best with an authoritative server and will not be equally useful offline.

That does not mean ignoring modern VCS lessons. TinyTree should learn from Git, Jujutsu, Sapling, Mercurial, and Arc so the local client remains fast, understandable, and pleasant even when the source of truth is the TinyTree service.

The constraint makes the source tree the durable unit of record. Projects, services, vendored code, generated code, team workspaces, and external mirrors become tiny trees and views inside that monorepo instead of separate repository silos.

A view is a focused projection of the monorepo. It can expose the files needed by a team, agent, CI workflow, or external mirror without pretending that subset is an independent repository.

Not all of TinyTree will be OSS. The client and API specification are intended to be open source, while the server-side implementation will remain closed source for the foreseeable future.

The client source and API spec will be available through tinytree.dev when they are ready. The API spec should give builders a useful foundation for crafting their own TinyTree automations in the future.

GitHub is still excellent at hosting Git repositories, pull requests, required checks, and merge queues. TinyTree is aiming at a different layer: built-in imports, exports, narrowed clone views, view-level access control, and tree-scoped automation.

That is a core goal. TinyTree should be able to import or mirror existing Git remotes into the monorepo, then export selected tiny trees or views back out as normal Git repositories when external compatibility matters.

Not by cloning GitHub-style branch pull requests. TinyTree should take more inspiration from Phabricator's Arcanist and Gerrit: the local client can send either one Change Request or an ordered Patch Set into the forge for review.

The initial version can wrap Git and push those changes through a server-side-only review ref. Over time, that path should become a TinyTree protocol with richer review and landing behavior, including server-side push rebase similar to Sapling.

TinyTree is not Jujutsu, but it takes inspiration from Jujutsu, Git, Sapling, Mercurial, and Yandex's Arc. The common thread is that source control can keep familiar workflows while rethinking the change model, storage model, and monorepo experience.

TinyTree's implementation centers on Rust and reuses existing libraries from the Jujutsu, Sapling, and Mercurial ecosystems where practical. Exact compatibility levels with Jujutsu and other non-Git VCS ecosystems remain open.

That is the intent. A change should remain recognizable as it is revised, rebased, exported, imported, or reviewed as a new patch set. Gerrit's Change-Id model is a useful reference point here.

Sapling is relevant for large-repo scalability and Git interoperability. Gerrit is relevant for patch set review. Mercurial Evolve is relevant for tracking rewritten history. GitButler and Graphite are relevant for stacked-change workflows. Pijul is a useful signal for patch-oriented data models.

A narrowed clone is more than checking out fewer files. It should materialize a limited subset of files and directories, download only the short history needed for the relevant commits, and lazily fetch the rest of the monorepo when the user or tooling crosses a boundary.

Built-in support means those narrowed clone views are discoverable in the TinyTree client. Different view trees, similar to Git worktrees, should also be able to share the same local object cache backend instead of duplicating repository data.

Starlark is common in large monorepo partitioning and build tooling, and its Python-like shape makes it more expressive than a pile of YAML conventions. TinyTree expects to use its own Starlark dialect, similar in spirit to Starlark Configuration Language, with TinyTree-specific behavior on top.

Early experiments should use Starlark for tree-transformation logic and hooks that can run on the client side and server side. Longer term, the same language should help manage monorepo configuration, view composition, and access control.

The goal is view-level authorization. Two users can operate on different projections of the same monorepo, with policy attached to the view and the underlying tiny trees rather than only to the entire repository.

No. TinyTree is for people and automation alike. The goal is a human workflow that feels good through a custom CLI, backed by a strong API layer for scripts, services, and coding agents.

Core operations such as blame and praise, code search, sending changes, reviewing changes, imports, exports, and view management should all have clear APIs that other tools can build on.

Not as the core product layer. The priority is the source control foundation: storage, review, views, imports, exports, hooks, access control, and local client behavior.

TinyTree should expose APIs that let builders integrate it into existing automation and coding-agent platforms. The project uses coding agents heavily to shorten the iteration cycle.

Because TinyTree is an SCM project at its core. Coding agents are likely to create more forks, branches, generated changes, and isolated code trees. The missing layer is not only orchestration; it is a better way to manage how those source trees diverge, review, rebase, merge, export, and come back together.

TinyTree starts from that source-control problem. The bet is that better VCS and forge primitives will matter more over time as both humans and agents produce more parallel code.