Prefer a visual version of this blog post? We have three videos available on the GitClear Youtube channel to demo:
Update: since we originally posted this blog, we have one-upped ourselves and launched a permanently free tier of subscription! 💸 Read more about getting GitClear free.
Original post:
The transition to remote work has clarified our daily use case. 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.
If you're first learning about GitClear, you could be forgiven for being skeptical about our claim to have "the best diff viewer." We'll use side-by-side screenshots below 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 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.
We hope you'll take GitClear for a spin and decide for yourself whether we've succeeded in building the best diff viewer.