Choose who can do what
An explicit trusted-member preset is planned for reading, writing, creating and sharing. Restricted resources keep their own rules, and administrator powers remain separate.
Git Pool · a PoolParty capability
Keep your project together,
on your pool.
Your code has a history. Your files have a place. Your collaborators know what they can access. Git Pool is being developed to bring that work together on the machines in your pool.
In developmentOff by default
Repository hosting, file access, collaboration and synchronization are not available yet. This page introduces the planned capability.
The planned Projects view
One project. Every part in view.
A project is more than a repository. Git Pool is designed to connect the code you change, the working copies on your computers, and the materials the work depends on.
One projectIn development
Repositories
Code, branches and history, with pull requests, reviews and issues alongside them.
Your working copies
See which device has a working copy and, when reported by that device, its branch and status.
Shared folders
Keep project documents and larger materials nearby, with their own access rules.
Linked versions
Connect a piece of work to the exact version of an asset it used, so later edits do not change the reference.
Each computer keeps its own Git working copy. Shared storage will not become one working folder that everyone edits at once. A linked version identifies source material; that reference alone does not mean its bytes have been verified, retained or backed up.
Work from a shared source
Keep the conversation with the code.
The planned repository service makes your pool the source of truth for code and history. Branches, pull requests, reviews and issues give invited collaborators a place to propose a change and understand why it was made.
A possible project
Build the site. Keep the source material.
A small team could keep a website’s code in a repository, drafts and photography in a shared folder, and links to approved asset versions in the same project. A reviewer could follow the proposed code change back to the material it uses.
Planned workflow · this is an example, not a live project or product screenshot.
Invited collaboration
Broad access when you choose it.
Clear limits where you need them.
The design supports trusted teams and collaborators who need access to just one part of the work.
Invite a collaborator to the project
Scoped guests are planned to work through a browser or Git connection, without joining your local network or enrolling a computer to store pool data.
Keep identities distinct
People, computers and agents will have separate identities and revocable permissions. Granting someone access to a project will not authorize an agent to run code.
Make privacy a storage boundary
Restricted files need storage and encryption arrangements that match who is allowed to read them. Hiding a folder in the interface is not enough.
Optional GitHub connection
Connect the parts you choose.
Per-repository GitHub integration is planned for teams that also work there. Keeping code on your pool will not automatically publish it or grant an external service access.
Review each direction before it changes anything.
Code import, code export, pull-request information and status reporting will be separate choices. Permissions, repository settings and branch protections need their own decisions about which system is authoritative.
Previews must show what can be mapped and what cannot. Diverging history, lost access and offline systems need an explicit resolution; silently overwriting history is not the default.
GitHub connection and synchronization remain unavailable. No credentials or private code are requested by this page.
Built in stages
Care for the whole project.
The plan includes coordinated recovery for repositories, review records, large files and linked assets. Recovery must respect current revocations rather than restoring old access.
More capability, with separate approval.
Large-file support, search, notifications, webhooks, migration and scoped agent access are part of the staged roadmap. Repository changes need one authorized writer at a time, including during recovery.
Each operational capability stays off until its own implementation, permission checks and recovery behavior are qualified and activation is separately approved. Git Pool does not enable Crew, automation runners or arbitrary repository hooks.
Current availability
Explore the direction.
Operational access comes later.
The foundation and project metadata contracts are being built and tested. The MAIN browser workspace can present information and capability states; that does not make it an authenticated repository or file service.
All Git Pool operations remain off by default. An information page or a preview cannot turn them on, invite a collaborator, connect GitHub or grant access to your pool.
In developmentExplore Git Pool in the workspace preview
The preview is separate from the public guide. Account-backed pool control and live project access still require qualification.
One PoolParty ecosystem
Part of your PoolParty workspace.
Explore the other experiences in your pool. Each has its own availability; these links do not share project data or grant access.
Chat Send a question to a model available through your pool, then see which model answered and why it was selected. Model choice depends on the computers and models you have connected. Available in beta PitchDeck PitchDeck is being developed inside PoolParty to shape a company or project story, arrange visuals and narration, and rehearse a presentation for Theater. In development Social Social is being developed for opt-in Spaces and Rooms where invited people can share clips, discuss moments, and gather in Theater. In development Theater Theater is in development for photos, films and generated worlds, powered by your pool and your own hardware. In development
