Bringing an existing repository

ProofGit works with Git history, not with a particular vendor. The source can come from GitHub, GitLab, Gitea, Bitbucket, Azure DevOps, a self-hosted forge, or another reachable Git URL. No vendor partnership is implied.

Choose the route that matches how you want the ProofGit repository to be maintained.

Push an existing clone

Create an empty repository in your ProofGit workspace, then add it as a remote to a clone you already control:

git remote add proofgit ssh://git@app.proofgit.com:2223/your-org/your-repo.git
git push proofgit --all
git push proofgit --tags

Git over SSH listens on port 2223, so keep the full ssh:// form. The shorter scp-style form connects to port 22 and will not work.

Use this route when your existing host remains authoritative and your own release process decides when ProofGit receives changes.

Import a repository

In the ProofGit forge, choose New → Migration, supply a reachable clone URL, and provide source credentials only when the source is private. The import copies the Git repository into ProofGit. What else can migrate depends on the source host and the import options it exposes.

Check the imported branches, tags, default branch and LFS objects before changing production remotes.

Configure a mirror

A configured pull mirror can keep the ProofGit copy aligned with an upstream Git URL. This is useful when another forge remains the system of record while ProofGit maintains an evidence-ready copy.

Mirror freshness depends on the configured interval and whether the upstream is reachable. Treat the displayed last-update state as evidence; do not describe a mirror as current until it has fetched the commit you expect.

Create the summary mirror

After the repository is present, pair it. Pairing creates a separate <repo>-llm Git repository of structured .llm folios. Generation is explicit and uses the model connection and spend boundaries configured for your organisation.

The source repository remains authoritative. ProofGit records the source commit beside derived facts so a client can ask for the summary, then inspect the exact source lines behind it.

Before switching a team

1. Confirm the default branch, tags and LFS objects.
2. Confirm that the ProofGit copy contains the expected source commit.
3. Pair the repository and generate its initial summary mirror.
4. Test cited retrieval against files your team knows well.
5. Only then update developer, CI or agent remotes that should use ProofGit.

Coming specifically from Gitea? The Gitea migration guide covers inherited forge behaviours and issue or pull-request migration in more detail.