Git History Red Flags in Vendor Code You Are About to Buy

When you review code from a vendor, contractor, or acquisition target, the git history tells you more than the code does. The final snapshot is the version they want you to see. The commit history is the version that actually happened, and it is much harder to fake. Who wrote the core, how the work was paced, whether the tests came before or after, whether the history was wiped clean right before you got access: all of it is in the log. If you get real git access and only read the files, you skipped the most honest evidence in the repo.

Why history is harder to fake than code

Anyone can clean up a working tree before handing it over. Format the files, delete the dead code, write a nice README, and the snapshot looks professional. The commit history resists that cleanup. To fake it convincingly, someone has to rewrite months of commits with plausible timestamps, messages, and authorship, and almost nobody does that work. So the log preserves the real story even when the files have been polished.

That makes history your best defense against a staged review. The same instinct applies whether you are reviewing contractor-delivered code or reviewing code in a data room: read what the team did over time, not just what the repo looks like today.

The red flags that matter

A single giant initial commit. When the history starts with one commit containing the entire codebase, the real history was thrown away. Sometimes that is innocent, a migration between systems. Often it is deliberate, hiding who wrote what and how, and it should trigger a direct question: where is the original history and why was it discarded?

Commit concentration in one author. If one person wrote 90 percent of the meaningful code, you are buying a bus factor of one. Ask whether that person is staying. If they are not, much of what you are acquiring walks out the door with them, and no amount of clean code changes that.

Tests added in a single late commit. Healthy development interleaves tests with features. When every test lands in one commit near the end, the tests were bolted on to pass the review, not to drive the design, and they often assert nothing real. This is the same tell as a one-shot final commit on a contractor project: work done for the reviewer, not for the code.

The pacing tells

Read the cadence, not just the content. Long silences followed by frantic bursts suggest a project that was neglected and then rushed before a deadline, which for a vendor deliverable often means the deadline was your review. Commits at odd hours in tight clusters can mean a solo person heroically cramming, which ties back to key-person risk.

Look at commit messages too. A history of thoughtful messages that explain why a change was made signals a team that thinks about maintainability. A wall of "fix", "update", "wip" tells you the opposite, and predicts how much context you will get when you inherit the code and try to understand a decision nobody documented. A repo intelligence pass over the history quantifies the ownership concentration and churn patterns so your read is grounded in the actual distribution, not a scroll through the log.

What clean history cannot save

History reveals process, and process predicts a lot, but it is not everything. A repo can have a beautiful, well-paced, well-authored history and still rest on a decayed architecture, because clean process does not guarantee good design. So read the history for the human and organizational risks, who wrote it, whether they are staying, how disciplined they were, and read the structure separately for the architectural ones. Do not let a tidy log talk you out of the structural audit, the way a clean lint report should never substitute for the real read that keeps code metrics from misleading you.

Ask for the real history early

The move that protects you: request full git history in your first access ask, before exclusivity, before the invoice is due, while you still have leverage to insist. If the seller gives you a snapshot only and resists handing over the log, that resistance is itself the finding. There is a reason the history is off the table, and you want to know it before you own the code, not after.