On average, GitClear implements ~5 new features while fixing 10-20 bugs every month. This is great if you're a GitClear customer! But less great if you're the chump that's expected to keep our blog and all of our ~70 help pages updated. 😅 If you're ever curious what we're up to during a period of silence, we strongly recommend peeking at https://alloy.dev, where you size up a Chart Glimpse that automatically summarizes the latest and greatest improvements from the past week/month/quarter. That chart gives us the license to spend 95% of our time focused on improving the product. If, like us, you're a product-centric company with more dev throughput than writing bandwidth, maybe your own Chart Glimpses could let your customers see what's new without you staffing a full-time writer?
At any rate, please enjoy this quick rundown of the biggest improvements to GitClear from Q4 2022 and January 2023.
linkCode comments with rich text editing
As described on our new Commenting on Code help page, there's a whole lot more ways to communicate with GitClear than there were previously:
Communicate in style with GitClear's new code commenting editor
If you're an Alloy.dev aficionado, you should recognize this editor as the basis for our sister product, the note-taking and todo app, Amplenote. Aka "the tool that we use to author and publish all of our help documentation and blog posts." Like Amplenote, GitClear now offers a fully integrated code editor based on CodeMirror. That means not only do you get syntax highlighting, but you get automatic indentation, highlighted brackets, batch indent or outdent, and lots more features that you would normally expect from a code IDE.
Unlike Amplenote, the GitClear code editor can automatically deduce what language to use for syntax highlighting based on the context of where the code is being written. For example, if you comment within an .scss file, the default language will be CSS. If you comment on an .rs file, the syntax highlighting will use Rust. In sum, the code block editor can handle almost every kind of programming language that GitClear itself can handle.
linkWhy prioritize a rich text editor?
At the moment, most customers discover GitClear when they're looking for a tool to help them follow the activity that's happening on their dev team. Since our first differentiating feature was a metric that can approximate developer energy, developing the Commit Activity Browser, historical stats, and other charts meant to follow whether the repo is evolving more or less quickly than it did in the past.
As of 2023, we believe that GitClear has proven itself among the very best options for Lead Developers and Managers that want to know what's happening on their team without scheduled meetings. 🎉
Having reached that milestone, what we've observed on our own team is that we only need to check our velocity once every day or two. It's very important to know, but it's not directly applicable to how we work on most days. What would be applicable to accelerating our progress every day: a code review tool that recognizes all the code operations/idioms recognized by Diff Delta, and lets us rapidly learn from teammates, or offer advice when code could be improved.
Our next update is on pace for a much bigger announcement: the opportunity to use GitClear to post and respond to pull requests. The set of features we have lined up for v1 launch is looking rather epic, most notably for all of the mileage that we expect to reap from integrating the OpenAI API for users who opt-in to it. One prerequisite to building "The Ultimate PR Review Experience" is allowing code commenting with a set of formatting options that goes beyond what contemporary tools offer.
If you would like to help beta test our AI-driven PR tool, please drop a line in the blog comments and we'll get in touch!
linkChart Glimpses in Enterprise
As we have said before, we believe that Chart Glimpses are one of the most powerful, high-leverage features GitClear offers. In any organization, there are stakeholders that need to know how a project is coming along, but can not easily be given access to GitClear for whatever reason.
Along with our newly launched API, Chart Glimpses are key to unlocking siloed information to show how rapidly a dev team is evolving its repo. Remember, a Chart Glimpse can communicate all of the tickets your team has worked on lately, and how much progress has been made on each ticket. And this information can be displayed anywhere that you can render HTML:
Your GitHub repo's readme file
Your project's wiki, task management, or note taking app
Your support website
Email to executives
A blog post
Don't sequester your commit activity in a corner. Bundle it together across all repos, and shine a light on it for the world to see.
linkNew notifications: Significant deleted code, test code, or documentation; high diff delta; high unplanned work
We've added five new types of notifications, as described on the updated Resource Notifications help page.
These notifications continue our work toward allowing GitClear users to follow the most important events happening on their team. In earlier versions of GitClear, staying on top of the most important updates often required daily visits to key reports, which could be tedious and inefficient. As can be seen on the aforementioned help page, we've now built about 10 different types of events that a GitClear user can subscribe to in order to know key events are happening without needing to visit GitClear daily.
All of these notifications will soon be displayed on a totally overhauled Highlights page that will emphasize allowing users to view preview of the charts where the most interesting activity has been occurring in the past weeks.
linkPublish commits to Chart Glimpse from commits list
When hovering on one's own commits on the commits list, a new option allows the commit to be designated as visible across all Chart Glimpses where the commit is applicable:
This is equivalent to writing a commit message that starts with #pub, but we've found it very common that in the midst of making commits, it can be hard to remember to include #pub. Sometimes, teams don't want extraneous tokens in their commit messages as well. This new icon addresses both problems.
linkRecently pushed branches list
This feature is now a few months old, but we hadn't previously blogged about it:
When you visit your list of recently pushed commits, you can click these branches to see the work-to-date that has been completed for any branch in any repo.
linkSmaller improvements & fixes
Allow importing from private user-specific repos in GitHub. Previously, it was only possible to import from private repos when they belonged to an organization. Now you can import private repos that belong to your personal GitHub account.
Commit Groups now build incrementally. This means that when you make a new commit to a large set of previous work (e.g., adding the 101st commit to a branch that will eventually become a PR), instead of rebuilding every file, we now rebuild only the files that were touched during the most recent commit. The end result is that, when pushing commits to large branches, the time spent waiting to see the updated commit group can be 90% faster than previous.
List of files travels when viewing a large diff/PR. Previously, if you scrolled down a multi-page diff, the list of changed files could be left behind, which left a wasteful gap on the left side of the page. This is now remedied, with sidebar and its relative illustration of how much work occurred in each file available throughout diff scrolling.
Files no longer marked as reviewed when they weren't loaded with code content. Previously there were some cases where a file might be marked as reviewed, even if the file had no displayed changes (because it was loading, or the changes were transitory), or if the attempt to load the file content was an error. Now, we won't mark a file as reviewed until it successfully loads, to ensure you'll get the chance to see every changed file upon subsequent visits. We've also improved the evaluation of whether a commit/commit group has been reviewed, such that it depends on at least 10% of the files within the commit/commit group being marked as aread (along with the existing requirement that the user scroll to the bottom of the page).