How GitTrim Fixes the Worst Part of Shared Libraries

The Pain of Shared Libraries

You fix a three-line bug… and suddenly eight downstream products break. Why? Because Git forces you to upgrade the entire shared library—even when only one file needs a patch. Every fix becomes a massive QA burden, a deployment nightmare, and a ticking time bomb for regressions.


I’ve spent years supporting vision systems in factory environments, where a shared library powered dozens of machines. One day, a five-year-old product in the field reported an obscure edge-case bug. The fix lived in a much newer version of our library—but that release also introduced dozens of unrelated changes and compatibility breaks for machines built years ago.

To apply the bugfix, we risked updating every single machine with a full-library upgrade, re-testing every feature just to change one function. It was high-stakes, high-stress, and fundamentally broken.


Why File-Level Versioning?

With GitTrim:

  • Every changed file gets its own semantic version bump—regardless of how many files you touch in one commit.
  • Dependent files only bump when they actually import or call your changed code.
  • Legacy safe: Machines or projects that rely on older file versions remain untouched—no more all-or-nothing upgrades.
  • Git-native CLI: No extra servers or services. Just install git-trim and start versioning at the file level.

This shift from a single-version-for-all to per-file version tracking gives you surgical precision in patching legacy systems.


Under the hood

GitTrim follows two simple rules:

  1. File-level versions: Every changed file must have its version incremented.
  2. Propagated bumps: If File B depends on File A and you bump A, GitTrim automatically bumps B’s version too.

These rules let you generate a project package with cherry-picked function versions—updating only what you need without hindering ongoing library development.


Example CLI Usage

# Bump a single file and its dependents
git trim bump src/encoder.py
# → encoder.py bumped to v1.2.0
# → image_pipeline.py auto-bumped to v3.5.0

In one command, you see exactly which file you changed and which dependents were updated—no hidden side-effects.


Who It’s For

GitTrim is built for teams who maintain long-lived, shared codebases where stability is paramount:

  • Embedded & industrial automation (factory vision, robotics)
  • Medical & safety-critical devices
  • Internal SDKs & platform libraries
  • Large monorepos where microservices or packages must evolve independently

If you’ve ever held your breath before merging a “simple” bugfix, GitTrim is for you.


We’re looking for early adopters to pilot GitTrim in their real-world workflows. If your team struggles with full-library upgrades, endless QA cycles, or fear of regressions—let’s talk.

👉 Join our waitlist at gittrim.com for early access and help shape the future of surgical versioning.


With GitTrim, you can finally fix one file—and leave the rest untouched.

Scroll to Top