Hey hey, long time no update! Anyone watching the GitClear Chart Glimpse has been witness to a flurry of improvements that we've deployed over the past few months. Our single biggest update is pull requests: it's now possible to review quality indicators & code for individual PRs. Along with that, we've also refreshed our Highlights notifications, added more context to the Commit Activity Browser, and added a new report that lets you see how your efficacy-per-developer is changing.
Here is the full menu of updates on the table for today, feel free to jump to the entrees most relevant to your use case:
Here is a run down of what we've built in the last few months for our customers.
This was the single biggest area of energy and focus since our previous update. We hold these truths to be self-evident: that, by 2025, humans will spend much less time reviewing each others' code than we did before LLMs. This is the perfect opportunity for a fine-tuned LLM to handle the hours of review that Senior Developers must currently dedicate to reviewing their peers' code.
Step one on our goal to be the most practical solution for code reviewers who want to leverage the full capability of a fine-tuned Llama 2: offer PR review. It's now available to all customers as a new tab under "Pull Requests" where you can choose "Code Review" to see a list of PRs underway. There is also a new help page dedicated to describing the various reports now available to accelerate reviewing a pull request.
The "Code Review" subtab of "Pull Requests" lists the most recent pull requests for the selected team, within the selected resource
Then you can drill the details for an individual PR:
Easy to toggle comparing this pull request to others
Every pull request has a tab dedicated to assessing its quality across many dimensions. One dimension is "how well does the pull request accord with code quality goals set for the repo?"
How does the pull request stack up against code quality goals that were set?
If you’re curious about the challenges of automating code review, you can read more about what we have learned in the process of launching our beta PR Review product.
Prior to 2023, GitClear could only interpret code granularity at a "file-level" or "line-level." This made it hard to get very specific about what was changing, or whether the code within a file seemed maintainable. Now, we have built systems capable of detecting
method, plus the inherited hierarchies associated with these concepts, in the following languages:
C, C++, C#
You will see more GitClear visualizations (especially those around file browsing) tap into the greater precision afforded by digesting how/where encapsulation is happening, and which functions are most heavily utilized, or bug-ridden.
Brain Methods are a common target for refactoring. And many Lead Developers find it contributes to file scannability to prevent 15,000 line files. Toward these ends, we've added some new Code Quality Targets:
There are now seven code quality targets that can be set on a per-repo basis
Specifically, you can now set per-repo targets for maximum lines per file, and maximum lines per function, Diff Delta per pull request, comment count per PR, maximum weekdays for an open PR, and maximum weekdays between activity of some sort on the pull request.
The Quality tab shows which functions changed during the pull request, and whether those changes pushed the functions/method size beyond the repo's targets:
List of largest functions present within pull request being reviewed
Our highlights page is now structured to be developer-centric, putting the notable recent achievements of developers and team members front and center. When viewing the page, users will see graphs noting these achievements, e.g.:
Developers can now assess where their energy has been spent relative to their team in the past year
The specific graphs shown will depend upon the notification type you have enabled. You can customize these by clicking the gear icon in the notification panel up top:
This ensures that you get notifications that are specifically tailored to you.
With developer-centric highlights, you'll be able to visually see the ways that your team stands out, and give credit to developers that have achieved new highs, either for themselves or relative to the team.
It can be easy for a busy Manager or Lead Developer to lose track of which pull requests are currently in flight, especially on a large team that might have 5+ pull requests open at a given time. The new "Recent activity" module addresses this challenge:
The default dashboard after login now shows outstanding pull requests and recently pushed branches
Clicking a pull request will fire up our new pull request review page ✨ to give an overview of how the pull request stacks up against others in its repo or entity.
For teams with a changing composition, GitClear's traditional accumulation-based stats leave something to be desired. If your Diff Delta increased by 50% over the past year, that's usually a good sign. But if your team size grew by 200% over the same period, that says something about the costs of extra coordination. Thus, our new Velocity -> Per Contributor Stats.
Each data point divided by active committers per repo
As with our existing Velocity stats, you can make Chart Glimpses out of the Per-Developer stats, so they can be added to the internal dashboards or repo Readme files where we often see teams post their GitClear charts. Learn more about Per-Contributor Stats here.
If you're looking to quickly assess where post-merge changes are coming from, and which PRs they apply to, you now have the ability to do this via our "PR list" sub-tab.
First navigate over to the PR list, at which point you'll see the option to filter for PRs with post-merge changes, up top:
After you check this, you'll see PRs with post-merge changes highlighted. You can click into "View Post-Merge Changes" and see a detailed list of commit(s) that went into this PR after merging:
From this, you can translate high level measures (abnormal post-merge work) into low-level causes (individual updates to work in a PR), and better assess process improvements.
By default, our retention window for daily stats is the most recent 30 days, for weekly stats is the most recent 6 months, etc. If running GitClear Enterprise, you can now adjust the retention window for detailed stats, allowing for longer retention and ability to see detailed stats from much further back.
This is expressed as a multiplier, so 2x would imply a two-month retention window for daily stats, one year for weekly stats, etc.
Note that this increases the amount of resource and space usage, so you should budget the resources for your Enterprise instance accordingly.
There is a new set of endpoints for GitClear API users: the Audits endpoints. Under many circumstances, the prospect of "more audits" isn't going to merit it's own h1 heading in a blog post. This time is the exception, because these endpoints let you tap straight into the data that GitClear uses to provide its customer graphs. Here is the data available from the Audits API.
If you are looking to win over skeptics within your company by proving that GitClear offers a more accurate evaluation of git data than competing options, the Audits API is tailor-made to let you prove that the data we provide matches your internal methods. If ever you should find that your data that doesn't match audit data, you can message our support team and we will either explain the methodology difference, or resolve the inconsistency as an urgent-priority task.
Long-term issue stats no longer undervalue previously completed issues. This was a tricky bug where issues completed 6-12+ months ago were often shown (in views like "Biggest Issues" tab) to have taken a small amount of Diff Delta. The problem was that the issues' often became associated with commits via their branch name (e.g., the "feature-321" lets us know that the commits on the branch are associated with issue #321), but after the work was merged back to default branch, a subsequent reanalysis of the commit would find no evidence the commit was associated with an issue (since its later branch is the default branch). This is now fixed by considering all of the historical branches a commit had appeared on when evaluating its issue in later months or years.
Allow committers to be added to teams without their associated repos. With the growing number of Enterprise clients GitClear onboards, we have discovered a growing number of cases where a developer participates on a team, but that developer's activity in a repo does not imply that the repo is under the purview of the team they exist within. Thus, we have updated our Team form to be more configurable in specifying whether a developer who is added should automatically determine which repos are considered "under team's watch."
ISO 27001 Certification End Stages. Not completed yet, but we have spent several more hours on this over the course of the past few months, and we hope to get yet another validation of our evolved security posture within the months to come.
There are a few features that we're especially looking forward to in the next month or two.
We introduced automated code summaries about a month ago, but they are currently limited by the 4k context window of the ChatGPT API. Also, some customers don't feel comfortable sending code line content to OpenAI. In the coming months, we will be firing up our own on-premises LLM, fine-tuned to summarize data in the style of a Lead Developer. We are working nights and weekends to lead the charge into a world where more tedious work can be offloaded to the LLMs.
We're going to leave this one ambiguous, but keep an eye on the Directory Browser in November and December. We've got some exciting improvements in store to bulk up the breadth of functionality offered by traditional blame views. Since GitClear recognizes moved lines, and tracks the history of a line as it moves across files and lines, we have a lot opportunity to explain how a line came up be, even if it originated long ago in a different file + function.