When a private equity firm acquired a mid-sized logistics software company in 2019, they did what acquirers typically do: interviewed the engineering leads, reviewed the architecture diagrams, and got a confident tour of the product roadmap. They liked what they heard. The deal closed.
Six months later, they had burned through two engineering managers, lost four senior developers, and were staring at a rewrite estimate that had grown from three months to eighteen. The codebase worked. The team seemed solid on paper. What had they missed?
A consultant brought in to assess the damage did something the due diligence team had not. She pulled the git history and read it the way a forensic accountant reads a ledger.
The Setup
The company’s product was a route optimization tool used by regional freight carriers. It had been built over eight years by a core team of six developers, three of whom were still at the company. The codebase had roughly 400,000 lines of Python and JavaScript, a reasonable test suite, and documentation that looked thorough until you tried to use it.
The commit history told a different story. Over eight years, the repository had accumulated just under 12,000 commits. That number sounds healthy. The distribution was not.
Three developers accounted for more than 70% of all commits, and one of those three had left the company two years earlier. More telling: the remaining two prolific committers had almost no overlap in the files they touched. In eight years, they had essentially built two separate systems that happened to share a database. When one of them resigned three months after the acquisition, a third of the codebase became archaeology.
What the Log Actually Contains
A git log is not just a record of changes. It is a record of decisions, and more importantly, the rhythm of those decisions.
Commit message quality is the first signal. Messages like “fix” or “wip” or “asdf” are not just lazy housekeeping. They indicate a team that does not think of future readers, including future versions of themselves, as important. The logistics company’s log was full of them. The messages that were descriptive tended to cluster around one author, which told the consultant that code review, if it existed at all, was not functioning as a knowledge-transfer mechanism.
The second signal is merge frequency and branch lifetime. Long-lived branches that merge in massive batches are a reliable indicator of integration avoidance. The logistics codebase had one branch, called “refactor-pricing,” that had lived for eleven months before merging a 40,000-line diff two weeks before a major customer demo. That single decision had introduced roughly a third of the known bugs the new owners were now responsible for.
The third signal is the geography of change. Most codebases develop hot zones, files that get touched constantly because they accumulate too many responsibilities. In a healthy codebase, those hot zones migrate over time as the team refactors. In this one, a single configuration file had been modified 847 times in eight years and had never been broken apart. It had become a graveyard of workarounds, each one added by someone who understood the file less than the person before them.
Why This Matters Beyond One Acquisition
The private equity case is dramatic, but the pattern it illustrates appears in much more ordinary situations: a startup evaluating a technical co-founder candidate, an engineering manager inheriting a team, a developer deciding whether to join a company.
Interviews are optimized for the interviewee. Candidates prepare answers. Even technical interviews, which have their own well-documented problems, test performance under artificial conditions. A commit history cannot be rehearsed. It is what a team actually did when no one was grading them.
Consider what a six-month commit log reveals that a two-hour interview cannot. You can see whether test coverage grows before or after production incidents (it should be before). You can see whether commit volume collapses every Friday afternoon, which might mean healthy work-life discipline or might mean a team that regularly leaves things half-finished before the weekend. You can see whether a declared architecture refactor actually happened or quietly died after two weeks. You can see who reviews whose code and whether that reviewing is substantive (look for back-and-forth on a PR) or ceremonial (a single approval within minutes of submission).
None of this requires special tooling. Tools like git log, git blame, and git shortlog have been available for decades. The analysis the PE firm’s consultant performed took about four hours.
What We Can Learn
The logistics company eventually stabilized, largely by hiring two developers who had previously worked together and had references the acquirer could check against their prior commit histories on open-source projects. That’s worth noting: public repositories give you exactly this kind of signal for free, which is one underappreciated reason why open-source contribution histories carry weight in hiring.
The broader lesson is about where signals are concentrated. Interviews measure how someone talks about their work. Code reviews measure how someone thinks about a specific problem on a specific day. A commit history measures how someone behaves over months and years, under deadline pressure, under low oversight, and when they’re tired.
For anyone evaluating a team or a codebase, the practical starting point is simple: ask for read access to the repository before the deal closes, the offer is accepted, or the partnership begins. Most people will grant it, and the ones who refuse are telling you something too.
Look for the ratio of fixes to features over time. A codebase where bug fixes increasingly outnumber feature commits is accumulating drag. Look for the longest-lived contributor and ask what happens to the product if that person leaves tomorrow. Look at the last six months specifically, not the lifetime average, because teams change faster than their histories suggest.
The logistics company’s post-mortem found that all of the warning signs had been present in the repository. Nothing was hidden. The due diligence team had simply not thought to look there, because the interviews had gone so well.
That is the thing about commit histories. They don’t know they’re being evaluated.
