The hardest work we've done in three years of programming GitClear has been trying to get our diff viewer to passable quality. When we first started this product, the ubiquity of diff software misled me into believing that diff viewers were a "solved problem." It would be a feature that we'd breeze through en route to the tricky tasks, like building a metric that corresponds to cognitive load.
What we've learned in thousands of hours over three years is that diff viewers are ubiquitous, but they are not a solved problem. In fact, the more we spent time thinking about the canonical diff view that every major tool presents (GitHub, GitLab, Bitbucket, VS Studio, Jetbrains, etc), all share features like
Most code is background highlighted to indicate "added" or "deleted." More specifically.
Limited interactivity. You can leave a code comment, but it's hard to know when the feedback is welcome.
"Unit of diff" is almost always a single commit, but sometimes a range of commits
The bottom line is that, aside from bits of coloring, you'd be hard-pressed to find consequential differences between any two diff viewers you looked at in 2020. Inasmuch as differences exist, they tend to regard background coloring or syntax highlighting.
So we built Commit Activity Browser. It's a modern breed of diff viewer that makes it possible to read less code, review the riskiest changes first (even before they get to PR), and keep code review in context. Context is probably the most underutilized learning cue neglected by the current generation of git providers and diff viewers.
linkA diff viewer that interprets code to save dev time
The fastest code to review is the code you skip over. GitClear helps developers skip about 30-40% more code than conventional diff viewers by recognizing moved lines, keywords, whitespace, and other .
linkCanonical commit viewer: Lots of lines
The canonical diff viewer (GitHub), showing some work done recently on Ruby on Rails
On the plus side, this diff assists viewers by darkening some strings to more quickly call attention to where an in-line change occurred. But the low contrast between the changed word and background isn't doing the reader any favors.
More generally, when reading the meaningful (changed) lines, we start at a disadvantage, because the ambient green/red background inherently reduces the contrast between a white background and the syntax highlighting that rests upon it.
Reviewing the ~50 highlighted lines in this diff might take an an intermediate developer around a minute.
linkGitClear diff viewer = less lines
Here is the exact same commit shown in GitClear:
The same Ruby on Rails diff shown via GitClear. If it's not animating and you want to see the original version, click the expander arrow on upper right corner of image
In our version, we try to focus the attention on lines where meaningful changes happened. Since so much of LoC is garbage and noise, there is quite a bit of efficiency to be gained by building on GitHub as the control.
linkMeta optimization: read fewer commits that matter more
Recognizing moves, keywords, and such reduces code to review by ~35%. It's a good start, but back in real life, most people don't review commits, they review pull requests.
We see pull requests as one prong among many that lead developers to review code. What other ways might people want to group reviewable commits besides pull requests?
Last 24 hours. "I wonder what X is up to today?"
Past few days. "What tickets has X been working on this week? Should I offer help or let them keep on trucking?"
By issue. "How was this ticket implemented? Did it introduce tech debt?"
By repo. "What are the biggest changes happening in my project lately?"
By file. "What types of changes have happened in this file over the past few months? In what file and line was the last meaningful change?"
Here's what we've created to allow the various types of browsing:
link
linkCode in context => faster learning
One of the biggest problems with the last generation of diff viewers is trying to keep a sense for how a particular commit relates to the full set of commits in the repo or the company.
The full set of Ruby on Rails commits adjacent to the previous commit
Click into it?
Clicking the bubble leaves the map of commits intact while showing details on the commit and the issue that the commit addresses
Especially if you're a manager trying to help a hire get ramped up, keeping this context offers a significant advantage.
linkA favorite code context: Issues
The final limitation of past diff viewers we'll discuss is that they don't connect back to their source: the issue trackers that drove the development. When a technical manager wants to see the code that has been written toward a particular issue, it's extremely convenient to click from Jira into the group of commits that implemented the ticket.
Connecting commits comes with still more perks. Have you ever felt frustrated that it feels like all the team is doing is fixing bugs? We can show how much of the team's work is being spent on features vs bugs lately.