Keep Git. Add Swarmfile.
Your git host keeps the code, the pull requests and CI. Swarmfile holds the files Git was never built for, and meets Git three ways: as an LFS server, as a clone source, and in a CLI that answers to the commands your fingers already type.
Three ways in
A Git-LFS backend
Keep GitHub, GitLab or your own server for code. Point lfs.url at Swarmfile and the big binaries go there instead. Stock git-lfs works, and so does git lfs lock.
git clone swarmfile://
A project with its git view enabled clones like any repo. The remote helper installs with the desktop app and does the conversion on your machine; the hub does no packfile work.
A CLI with git habits
swarmfile speaks commit, branch, switch, restore, merge, tag and changelists. add, stash, reset and clone run the real operation; push, pull, rebase and friends tell you what to do instead.
Git-LFS: keep your host, move the big files
Commit one file to your repo. Your git remote never changes, and the pointers already in your history keep working.
# .lfsconfig, committed to the repo root
[lfs]
url = https://hub.swarmfile.com/orgs/<org>/lfs/<project>- Stock
git-lfspushes objects up to ~100 MB. The bundledswarmfile-lfstransfer agent does chunked, resumable pushes up to 256 GiB per object; re-run an interrupted push and it picks up where it left off. git lfs lockworks, and on a path that is also on the drive it is the same lock the desktop app takes.- Both directions: a file saved on the drive is
git lfs pull-able by its oid, and a pushed object can be reflected onto the drive as a real file. - Walk away any time:
git lfs fetch --allbrings every object home, and your repo never depended on us for anything else.
Encryption caveat. LFS objects uploaded directly by the stock client, and objects of 64 MiB or more sent by the desktop app’s built-in agent, are stored without application-layer encryption. Git-LFS isn’t available on end-to-end-encrypted projects. If a binary must be encrypted at rest, keep it on the drive. How Swarmfile encrypts.
git clone a project
Once a project’s git view is enabled, its history clones and fetches with plain git:
git clone swarmfile://<org>/<project>
git fetchThe git-remote-swarmfile helper ships with the desktop app. It turns Swarmfile history into git objects on your machine, so the hub never builds a packfile. How Git and Swarmfile history line up.
What works today, and what doesn’t yet
| Works today | Notes |
|---|---|
| git lfs push / pull / fetch with the stock client | No fork, no plugin. Objects up to ~100 MB per request with stock git-lfs. |
| git lfs lock / locks / unlock | When the path is also on the drive, it is the same lock the drive uses. |
| The swarmfile-lfs transfer agent | Chunked, resumable pushes up to 256 GiB per object. |
| git clone / git fetch of a git-view project | Through the swarmfile:// remote helper, including --depth shallow clones. |
| Git habits in the swarmfile CLI | commit, branch, switch, restore, merge, tag, changelists, add, stash, reset. |
| External CI status checks on merge requests | Your CI reports a status; the merge request shows it. |
| Not yet | Notes |
|---|---|
| git push of commits to Swarmfile | The git view is read-only: clone and fetch. Commits are made on the drive or with the CLI. |
| git clone of an end-to-end-encrypted project | The helper refuses E2E projects, and git-LFS isn't available on them either. |
| --shallow-since and --shallow-exclude | Refused with a clear message. --depth, --deepen and --unshallow work. |
| One-click GitHub App onboarding | Built, coming soon. Until then, commit an .lfsconfig as shown above. |
Weighing it against your current setup? Swarmfile vs. GitHub LFS, or the developer quickstart.
Point one repo at it.
Public projects are free and need no card. Private projects come with a trial.
Card on file, nothing charged until day 7. A trial covers up to 2 seats; add more once it converts.