Monolithic Git Sizing¶
This page captures the measured repository, worktree, and dependency sizes from the May 12, 2026 sizing analysis for the BFDev monolithic Git transition.
Summary¶
The current measured upper bound for one full monolithic bf-dev instance with host-installed dependencies is 11.8G.
Each additional worktree adds about 606M of source checkout size. If that worktree also installs host dependencies, its measured upper bound is 8.5G.
That gives these practical planning numbers:
| Instance shape | Source checkout | Host dependencies | Upper bound total |
|---|---|---|---|
| Base monolithic repository | 1.2G |
7.9G |
11.8G |
| One additional worktree | 606M |
7.9G |
8.5G |
| Base repo + 5 extra worktrees | derived | derived | 54.3G |
What drives the dependency size?¶
The measured dependency upper bound is 7.9G per full host-installed instance.
It is made up of:
3.3Gofnode_modulesacross the JavaScript projects4.6Gof.venvdirectories across the Python projects
The largest measured contributors in the report were:
| Dependency type | Project | Size |
|---|---|---|
node_modules |
betterfleet-bnl-ui |
1.7G |
node_modules |
bf-manage-web |
1.4G |
.venv |
bf-digital-twin |
2.8G |
.venv |
bf-manage-core |
353M |
.venv |
bf-schedule-creator |
335M |
Clone measurements¶
Typical developer clone measurements from the report:
| Clone mode | Size | Time |
|---|---|---|
| Full clone | 1.2G |
17.345s |
Shallow clone (--depth 1) |
758M |
17.391s |
The measured shallow-clone size is smaller, but the timing difference in this run was negligible.
Sparse checkout measurements¶
The report also measured sparse checkout as the main answer for developers or pipelines that only need one service directory:
| Sparse checkout target | Size | Time |
|---|---|---|
bf/manage-web |
119M |
7.836s |
bf/manage-core |
38M |
6.288s |
bf/digital-twin |
314M |
8.509s |
Measured command shape:
git clone --no-checkout --filter=blob:none <repo>
git sparse-checkout set <directory>
git checkout main
How to interpret the numbers¶
- These figures are an upper bound for fresh instances using typical clone and dependency-install commands.
- Host-installed dependencies duplicate per worktree if you run
npm installoruv syncinside each one. - Docker-based workflows reduce that duplication pressure because container layers are reused instead of recreating every host dependency tree in each worktree.
- The main source-checkout overhead of extra worktrees is comparatively small; the dependency trees dominate total storage use.
Guidance¶
- If you expect to keep several parallel worktrees, prefer Docker-backed workflows where practical.
- If you only need one or two services locally, prefer sparse checkout to keep editor indexing and filesystem load down.
- If local storage becomes a problem, investigate the largest dependency owners first, especially
bf-digital-twin,betterfleet-bnl-ui, andbf-manage-web.