Derisk Your Release (with hard data)

Unlock the full value of your exception stack traces, coverage reports, JIRA tickets, and linting violations. We aggregate that data to assess the risk of your releases, help you identify risky changes, prevent bugs from making it to production, and fix the bugs that do much faster.

A diff for the 21st Century



The Stacktrace of the Future

ArgumentError: bad argument (expected URI object or URI string)
Developers connected to lines in functions, ordered by score


  • (87)
Developers connected to lines in functions that have changed since deploy, ordered by liklihood of causing error


  • (45)
Commits connected to lines in functions that have changed since deploy, ordered by liklihood of causing error

Suspect Commits

lib/notifier.rb:13 - post
lib/notifier.rb:4 - notify
bin/conglomerate.rb:90 - block in index
bin/conglomerate.rb:74 - each
bin/conglomerate.rb:74 - index
bin/conglomerate.rb:126 - main
bin/conglomerate.rb:144 - <main>

How's It Work?

As a developer at a few different mid-sized software companies, I constantly ran into the same problems: How risky is it to change one line versus another? Which product person, QA contact, or developer should I ask about the intent of the functionality? Just looking at the Git Blame couldn't answer this. Often lines were only moved from one module to another, indented or outdented for a conditional, or even occasionally Git would think a line changed, even though it didn't.

The problem worsened as I became more senior. Now, all the questions I used to ask were getting directed at me. And, on top of that, I was tasked with reviewing multiple thousand-plus line diffs per day. I couldn't pay attention to every line, and nothing would help me focus in on the lines that were particularly risky — lines historically associated with bugs in our project management software, or lines that occurred in an exception stacktrace, or lines that weren't covered by tests.

I asked co-workers and friends for months if a product existed that could answer these questions in depth and reliably. All the responses were more or less the same: "No, but you should build it. That would be awesome." So I built it.

GigaDiff tracks the history of every line, how it changes over time, and any stacktraces, JIRA tickets, or test coverage associated with it. It aggregates this data at the file, directory, and repository level. You can figure out the churn of a file or the business value of a directory (according to your time-tracking, business value, or story point estimates). And you can weigh that against how many errors and bugs are associated with a file or directory to make intelligent, data-driven decisions about when to address tech debt.