The further we get building GitClear, the more fun it is becomes. When we first put a team on GitClear in early 2019, it was a slog. Customers liked being able to see how policy decisions affected team output, but GitClear wasn't the sort of tool that you'd use every day, which made it easy to forget about.

The transition to remote work has clarified our daily use case. It helped us recognize that we must win based on product value. With today's pricing and feature updates, it's hard to find any other code review tool that goes as deep into exploring what a next-gen diff viewer should look like 💅. Since we already had a commit interpretation engine built for code measurement, we needed to make the UX intuitive enough for customers to recognize the benefits without a demo.

Most people who will read this article are learning about GitClear for the first time. Having never heard of this company, these people will be inclined to dismiss our claim about having "the best diff viewer" because we lack credentials. And that is warranted skepticism. We'll use the next few hundred words supplying evidence to back up this extraordinary claim, so you can decide for yourself how crazy we are.

linkThe road to diff clarity

We had to invent our own lexicon to describe the "operations" and the "idioms" that programmers use in diff viewer terms. This lets us interpret code in a human-like fashion, which saves a lot time by canceling out the lines that code reviewers don't need to think about. It also helps teammates recognize the cadence at which different programmers operate.

link🗜️ Step one: reduce lines for review in diffs of individual commits

In terms of specific examples that show how GitClear's diff viewer compares to the industry standard, consider this recent commit from Rails, shown in the canonical diff viewer vs. GitClear:

A recent Ruby on Rails diff. The canonical diff viewer (GitHub link) at left, vs GitClear version at right, with borders added to emphasize blocks of changed lines. More about these examples in our first article on why the canonical diff viewer is lacking.

When reading the meaningful (changed) lines, the canonical diff viewer starts at a disadvantage, because the ambient green/red background reduces the contrast of the code text compared to a white background. Contrast is reduced further where inline character highlighting shares the hue of the ambient background.

The "secret" to hiding so much code is recognizing and contextualizing moves, keywords, blank lines, and other operations that don't materially change the nature of the program. You can still see every line of the diff, but the lines most likely to matter are the prominent ones.

Step one already reduces lines of code to review by at least 30% over the canonical diff viewer, mostly by reducing the emphasis on moved code and keywords.

link🔕 Step two: combine commits to hide the "canceled" code

Commit groups glue together commits that implement a particular ticket, allowing code reviewers to ignore all the early code that got sketched out during the initial commits.

A beta version of "Commit groups" has been available since our company was known as "Static Object," but the beta version was never tuned to connect commits like a human does. Commits would group together based on heuristics, even though most teams think in terms of "Jira tickets" or "pull requests."

As of today's release, you can choose how to glue together work done by developers who you follow:

Configure commits to be glued together, and spot commits that aren't part of any known issue tracker ticket

You can now glue commits together by the issue they implement or the pull request in which they appear. You can also control how much work you view at once, and whether you want to continue to see commits you've reviewed previously when you open the code for an issue/PR.

An incidental benefit of the new commit grouping options: implicit differentiation between "commits made toward resolving a ticket" vs "commits made in service of some undocumented goal." Looking at the screenshot above, the circles with dots in them are work that doesn't correspond to any Jira ticket. On some teams, it's important to minimize work on undocumented matters.

Bottom line: If you review commits, we can save you time. Probably a lot of it. We can also make it faster and easier to leave feedback, to catch problems before PR, and to recognize problem patterns among the team's developers.

linkCelebrating better quality with a new, lower price

Since we don't intend to employ a traditional sales team, we will now offer the diff viewer above to any team for $9/active developer/month. It's called the "Commit Activity Browser" in GitClear parlance, and it's one of many features we're including in our new $9/month plan.

Until today, our pricing started at $300/month. Now, you can sign up as even a single developer for just $9/month. 💸

Below are our new prices in full. Here is how our pricing compares to our closest competitors.

There has never been a better time to give GitClear a try, what do you say?