Multiple Git repositories. One workspace.

No. This is a fundamental requirement of the design. Your public repository stays a completely standard Git repository - fork, clone, branch, commit, push, pull request, all without GitOne installed and without any knowledge that it exists.

Nothing breaks. Each managed repository under .gitone/repositories/ is an ordinary Git directory with its own metadata, index, HEAD, refs and hooks. Point plain git at one with --git-dir and it behaves exactly as it always did. There is no proprietary format and no lock-in.

No, and that is a decision rather than an unfinished feature. Splitting one history along path ownership rewrites every commit, and each commit that touched two repositories becomes two unrelated commits describing something that never happened. It also cannot deliver what it appears to promise: if the repository was ever pushed, the old objects stay on the forge no matter what you rewrite locally. So migration converts the project layout, not the history. The managed repositories start empty, and your complete old repository - every commit, branch, tag, stash, reflog, hook and remote - is copied to a verified backup under .gitone/migration-backup/ that GitOne never removes, readable with gitone backup git -- log --all and restorable with gitone backup restore. If you do want a split history, rewrite it with a dedicated tool before you migrate.

No. It never reads your file contents. There is no secret scanning, no data classification and no entropy check. A private key inside src/ is published like any other owned file unless its path is explicitly covered by rules.protected_paths. GitOne enforces where a path may be published - not what is inside it.

No, and it is important to be clear about this. Everything sits in one directory that your shell, editor, backup tool and every other local program can read. GitOne is not an access-control boundary. It decides which repository may publish a path, which is a boundary that matters when something leaves your machine.

The file itself, no - it is a reserved path. gitone add .gitone.local.yml refuses with PATH003, listing it in a repository is CONFIG003, and if it reaches an index another way gitone doctor reports it. Setup writes it into .gitignore for the same reason. What you can do is declare those repositories in the committed .gitone.yml instead, and sometimes that is the right call - a team where everyone should get the same repositories, for example. Just be clear about the price: their names, remote URLs and path patterns become readable for everyone who clones, which sketches your internal structure even though not one private file is published. That is a judgement only you can make, and the default is the careful one.

gitone pull and gitone switch refuse that commit instead of applying half of it, and name the command that reviews it: gitone reconfigure --pull or gitone reconfigure --switch . It prints one preview - what is added, retired or renamed, how many existing local paths each new pattern claims, and every remote it will contact - and asks once, with No as the default. An added repository is then created, fetched and checked out. A removed one is retired rather than deleted: its complete Git directory moves to .gitone/retired/, the files it tracked stay on disk untouched, and the command refuses outright while it still holds commits its origin does not have. A rename is never guessed - notes disappearing and journal appearing is a retirement plus an addition unless you declare gitone reconfigure --pull --rename notes=journal, which moves the existing repository and keeps its history.

Not yet. Linux and macOS, amd64 and arm64. Windows is deferred rather than rejected, but nothing is promised.

There is no .git/ in the project root, so bare git commands find nothing. You can point Git at a managed repository with --git-dir and it will work - but every safety check GitOne performs is bypassed when you do, which is exactly the situation the tool exists to prevent. Use GitOne for publishing. The usage guide’s Manual Git repairs section covers explicit human repairs.Manual Git repairs

Yes, with plain Git against one managed repository at a time: git --git-dir=.gitone/repositories/{name} {command}. GitOne rejects unsupported commands instead of forwarding them. Running plain Git bypasses GitOne’s safety checks and multi-repository coordination. Commands that modify branches, refs, indexes or working-tree files can leave the managed repositories out of sync. Use this only when you understand the resulting state, then check the project with gitone status and gitone doctor.

Yes. Every operation is a native git invocation against a real repository, so your Git configuration, hooks, credential helpers, commit signing and Git LFS filters all run as they normally do. GitOne stores no credentials of its own.

Not yet. They are rejected with CLI001 rather than forwarded to Git, because coordinating them across several repositories safely is design work that has not happened yet. For a diverged branch, follow Resolving diverged history in the usage guide: inspect, merge within the named repository, resolve or abort conflicts, then check and publish through GitOne.Resolving diverged history

No. Submodules are not supported at all, and a nested or bare Git repository inside a managed path is reported as PATH003 rather than silently handled.

Only as a deliberate alias inside one repository, such as .claude/skills -> ../.agents/skills. The stored target has to be relative and non-empty, resolve inside the project, exist as a regular file or a real directory, be reached without passing through another link, and belong to the same repository as the link. A directory target needs at least one relevant path below it, all owned by the same repository. GitOne owns the link path itself and never traverses it. Absolute, escaping, dangling, cross-repository, chained and cyclic links are PATH003, and so is any link that is or reaches .gitone.yml, .gitone.local.yml, .gitignore, .gitone/, .git/ or a protected path - GitOne never opens such a target.

The operation stops with PATH002. Duplicate patterns are rejected earlier as invalid configuration with CONFIG003, but patterns from two repositories are allowed to overlap in theory - the error lands on the concrete file, not on a guess about one. There is no priority rule and no most-specific-match rule - deliberately, because either one turns "where does this file go?" into something you have to work out instead of read.

The tool has none. GitOne runs entirely on your machine with no telemetry, no update check and no account, and contacts nothing but the Git remotes you configured yourself.

Yes, and not only those two. Remotes are configured per repository, so GitHub, GitLab, Codeberg, Gitea, Forgejo, Bitbucket, a company server or a bare SSH path can sit side by side in one working directory - GitOne calls the same native git for each. Only origin is used by fetch, pull and push. A repository without a remote works for every local command; only pushing it fails.

No. Those orchestrate builds, tasks and dependencies inside one repository. GitOne does not know what a build is. It decides which of several repositories owns which path, and it is happy to sit underneath any build tool you like.

They use gitone instead of git, read gitone status --json for machine-readable state, and get a hard refusal instead of a guess when a file is unassigned. There is a ready-made instruction block above that you can paste into your AGENTS.md or CLAUDE.md.

MIT. GitOne is open source and the underlying repositories stay compatible with standard Git, so public contributions work exactly as contributors expect.