Import

Bring an existing Git repository into Fabric with its history intact.

Import a Git repo

fabric import ./my-project

Fabric assumes one repository per account, and import replaces that repo wholesale with the project’s history. So before you import over an account that already holds work, check what’s there:

fabric repo status      # empty, or a file count + the most recent change

If trunk already holds files, import asks you to confirm first (it won’t clobber silently). In --json or any non-interactive session there is no prompt to answer, so pass --force to opt in:

fabric import ./my-project --force

Importing into an empty repo needs no confirmation.

This replaces your repo with the project’s full history: Fabric runs git fast-export for you and maps commits, trees, and blobs into native ops with a per-commit frontier. Each original Git SHA is preserved as an attribute, so history stays faithful (authors and dates included). The repo is also relabeled with the source folder’s name (importing ./my-project names the repo my-project).

import advances your trunk to the imported head and blocks until the mint finishes. To get the imported files onto disk afterward, clone trunk directly:

fabric clone --at trunk      # read-only snapshot of the imported tree

To start editing, fork a change off the new trunk and clone that:

fabric change create "tidy imports"
fabric clone

A bare fabric clone (no change create) materializes the most-recent change, which may be an existing change rather than your import. After an import, use fabric clone --at trunk or fork a change first.

To nest the imported project under a subfolder instead of replacing the repo:

fabric import ./my-project --into packages/legacy

No repo setup is needed beforehand. Fabric provisions your repository on first use. See fabric import --help for the full set of options.

Large files and binaries

Real repositories import fine, including large ones. Diversion to object storage is by size only: a file over the size cap (a few MB), text or binary, is diverted to Fabric’s object storage as a content-addressed pointer that round-trips on clone, so large assets don’t bloat the history stream.

A small binary (a PDF, an icon, a short ANSI log) imports inline: its bytes ride in the operation log itself, so it round-trips byte-for-byte on clone with no object-storage round-trip. It is neither diverted nor dropped.

Pass --inline-large to turn the diversion off and send every file inline in the upload stream instead. This does not drop anything: it keeps the raw bytes in the stream, base64-encoded (about a third larger). A history with big files can then exceed the request size limit and fail with a 413 Payload Too Large, so prefer the default. (--skip-large is the old name for this flag; it never dropped files, so it was renamed.)

The remaining history stream (commits, trees, and text) is staged server-side while Fabric mints it, so an ordinary project’s history is not limited by message-queue payload size. A stream over 1 GB after large files are diverted is rejected up front with a clear message naming the size and the usual cause (large committed binaries still in history), rather than a generic error. If you hit that, remove those files from history or import a smaller ref.

Imports resume. If an import fails partway (a network drop, a transient hub error), just run fabric import again: object storage already holds the large files it uploaded, and the history stream is keyed by content, so a re-run reuses what already made it across instead of re-sending everything from scratch.

Leaving for plain Git

Adopting Fabric is reversible: you can hand a project back to plain Git at any time, files and full history intact. This is the no-lock-in guarantee, the exact inverse of import.

Review comments do not go with that export. Git stores file bytes, and a line-anchored comment is not file bytes, so a Git repo has nowhere to put one. This matches GitHub, where pull-request review comments live in the platform and never in the Git objects: a plain git clone of an exported repo sees clean source with no review threads mixed in.

Nothing is lost on the Fabric side. Comments live in the operation log alongside the code, so moving a repo from one Fabric hub to another carries them across in full: the comment history travels with the operation log, not through Git. Git is the lossy interchange format; the operation log keeps everything.

Why this matters

Import means adopting Fabric costs you nothing up front. You can move an existing project in with its full history and try the live, append-only model without rewriting anything by hand.