There are ten questions about a repository that the analytics tool answers and the log command cannot, and the list is the argument for why the tool exists, because each question is a real question that someone on a real team has asked, and each one takes either a fragile one-liner or an afternoon of log archaeology to answer with the log alone. The questions are not metrics for a dashboard; they are the questions that come up in the standup, in the planning meeting, and in the 2 a.m. incident, and the tool's job is to make the answer a command instead of an expedition.
The first is the hotspot question: which file has been changing the most in the period, and is it changing because it is load-bearing or because it is broken. The second is the weekend question: what fraction of the commits happened outside working hours, which is the burnout signal that no status report ever captures, because the status report measures output and the weekend ratio measures cost. The third is the branch question: what is the ratio of pull-request commits to direct pushes, which is the process fact that the team argues about and the data settles. The remaining seven are in the section below, each with the command that answers it and the reading that turns the number into a decision, because the question is only worth asking when the answer changes something, and these ten change things.
Lists are the format the reader can scan, and the scan is the feature, because the feature is the entry that the reader stops on, and the stops-on is the one that was the answer. The entries below are the ten that earned the slot, and the earned is the part that the filler does not have, because the filler is the entry that pads the count, and the pad is what the reader sees, and the sees is what the trust loses. The context is gitpulse, Git analytics in your terminal: file hotspots, commit patterns, branch strategy, contributor impact., and the context is the part that makes the entries the specific ones instead of the generic ones, because the generic entry is the one the reader has read before, and the read-before is the one that does not stop the scroll.
Onboarding a New Repo in 60 Seconds
The worst moment in a developer's life is opening a repository they have never seen: no documentation, a multi-year history, and a codebase that looks the same in every folder. The analytics turn that moment into a sixty-second orientation. The hotspots tell you where the action is — start reading there, not at the README. The contributor impact tells you who to ask when the code does not make sense. The branch strategy tells you how changes actually get in, which is the one process fact that documentation never gets right. Inherited projects are the common case, not the exception: new job, new team, acquired codebase, open-source contribution. A tool that compresses the first hour into the first minute pays for itself on the first use. The sixty seconds buy you something rarer than time: a map, so the first day is spent building context instead of stumbling through directories hoping the important file announces itself.
Branch Strategy as a Number
The branch strategy is a process fact, and the process fact becomes a number when the report counts the pull-request commits against the direct-push commits over the period. The ratio is the strategy: a team that merges through pull requests shows the ratio in one direction, a team that pushes to main shows it in the other, and the mixed team shows the split, and the split is where the policy lives, because the policy is usually by area instead of by rule, and the area is what the ratio reveals when the report breaks the split down by directory. The number is not the verdict. The verdict is the conversation the number starts, and the conversation is the one that used to take the meeting and now takes the slide, because the slide is the last three periods of the ratio, and the three periods show the trend, and the trend is what the policy argument is about. The number ends the fight by making the fight about the trend instead of the memory.
The 30-Second Report
Run the tool with no arguments in a repository and you get the current month, summarized: the hot files, the commit shape, the branch behavior, the top contributors by impact rather than commit count. Thirty seconds from typing the command to having a picture of the repository that the log would take an hour to assemble by hand. The design goal was a report you would actually read, which means short enough to fit on a screen and dense enough that each line earns its place. I use it as a standing habit: first command of the week in any repository I am active in, the same way some developers start with status. The habit is the point. A report that takes ten minutes to generate gets run once a quarter. A report that takes thirty seconds gets run every Monday. The frequency is the feature, because the value of repository analytics is in the delta — what changed since last week — and the delta is only visible if you look often enough to see it move.
CSV Out: Health Reports Without a Dashboard
The tool can export its findings as CSV, and that one flag is the answer to the dashboard question. The standard objection to CLI analytics is that nobody will read the output in a terminal. Fair. So the output becomes a file: a health report, attached to a message, emailed to the team on the first of the month, dropped into a spreadsheet that the tech lead already maintains. No server, no subscription, no infrastructure project. The data leaves your machine only when you decide it should, and the format is one that every tool you already have can open. For most teams, the right analytics infrastructure is a file and a habit, not a platform. The file is the report; the habit is the monthly export and the five-minute read. Everything else — the dashboards, the integrations, the subscriptions — is what you add when the file-and-habit version stops being enough, which for most small teams is never, and for the teams where it is, the CSV is the import format they will thank you for.
Reading a Report You Did Not Author
The report is a tool for the person who is not the committer, and the non-author is the larger audience: the tech lead reading the team's repository, the new developer reading the project they just joined, the reviewer reading the area before the review. The reading skill for the non-author is the same three passes the author uses, and the passes are the structure. First pass is the shape: the total volume, the active files, the contributor count, and the shape is the one-paragraph summary of the project's state. Second pass is the concentration: the hotspots, the areas where the energy is, and the concentration is the map of where the project is spending itself. Third pass is the change: the period over period delta, and the delta is the direction, and the direction is the part the summary needs, because the summary without the direction is the photograph, and the photograph is what last month's summary was. The three passes take the length of the report, and the report is the part that does not need the author present.
The Compare Range: Two Branches, One Answer
The compare flag takes a range and answers the question the branch list cannot: what is the relationship between the two branches, and what does the relationship cost? The main-to-develop range is the classic one, and the report is the difference: the commits on develop that main does not have, the distribution of the commits by person, the files that are hot on both sides. The hot-on-both is the collision warning, and the collision warning is the part that saves the bad merge, because the bad merge is the merge where both branches changed the same lines, and the same lines are what the report flags before the merge attempt. The range is also the feature review input, when the question is what did the feature branch change and who will need to know, and the answer is the file list with the contributor column, and the file list is the review scope, and the review scope is what the range computes instead of the human who has to walk the diff. The one command is the answer the meeting used to build by hand.
The Hotspot Table, Column by Column
The hotspot table is the center of the report, and the columns are worth reading in order, because the order is the reading. The first column is the file, and the file is the unit of the measurement, which is the unit the team thinks in, because the team argues about files instead of commits. The second column is the change count in the period, and the count is the energy measurement, and the energy is what the file is spending. The third column is the distinct contributors, and the contributors are the coordination cost, because the file that five people touch is the file that five people wait on. The fourth column is the revert share, and the revert share is the understanding cost, because the reverts are the changes that did not stick, and the not-sticking is the signal that the area is not understood. The four columns together are the diagnosis, and the diagnosis is the part the single-column view, the change count alone, does not give, because the count without the context is the number that argues for itself.
The Period Flag: Why Since When Is the Whole Interface
The analytics question is always a question about a window, and the period flag is the window. The month view answers the what-is-happening-now question, the quarter view answers the what-has-been-tending question, and the year view answers the what-is-this-project question. The same repository reads completely differently in the three windows, and the different reads are the feature, because the feature is the time axis, and the time axis is what the log command does not give you without the date math and the merge-commit handling that the one-liner gets wrong on the third try. The default period is the choice the tool makes for you, and the default is the quarter, because the quarter is the window where the pattern shows and the noise is still low. The flag is the escape hatch for the specific question, and the specific question is the one the standup raised, and the standup question is the one the report should answer in one command instead of one afternoon.
The 2>/dev/null Bug: How I Learned to Test Where Users Are
A recent release was a fix for a bug that had been silently present for three months: a shell redirect that is fine on Linux and macOS and quietly wrong on Windows, where stderr handling behaves differently. The tool ran, produced output, and the bug only showed up as missing data for a subset of users on a subset of platforms. The lesson is not that I made a mistake. The lesson is that a CLI tool's test matrix has to include the platform where your users are, not the platform where you are. Three months of silent wrongness is longer than most bugs survive in a well-tested product, and the fix was one line. But finding it required a user report, not a test. That gap — between the platforms you test on and the platforms your users run on — is the most expensive gap in a cross-platform CLI, and it is the one that never shows up in your own usage because your machine is the one platform that always works. The fix was a line. The lesson is a test matrix.
What Measuring Lots of Repos Taught Me
After running the same set of measurements across a large number of repositories — my own projects, client work, and public repositories from a range of stacks and team sizes — a few patterns held up consistently. Hotspots concentrate: a small fraction of files accounts for the majority of churn in almost every codebase. Commit patterns correlate with team size more than with team health: small teams look erratic, large teams look steady, and the middle is where the interesting data is. And the branch ratio is more stable over time than anyone expects — teams do not really change their shipping process, they change the people. The tool was designed to answer one question per repository. Measuring hundreds of repositories let the data answer a question I had not thought to ask: the shape of a codebase is more determined by its size and its people than by its technology, and the technology shows up mostly in the noise. The design decisions that followed — the default period, the impact weighting, the ratio as a headline metric — are all consequences of those patterns.
Commit Patterns and the Burnout Signal
Commits have a rhythm, and the rhythm is a health metric. The analytics look at when commits happen — by hour, by day of week, by streak — and the pattern is more honest than any survey. A team that commits steadily on weekdays is one kind of team. A team whose commits spike on Friday nights and Saturday mornings is another, and the difference is visible in the data without asking a single person how they are doing. I am not saying commit timing equals wellbeing; it is a signal, not a verdict. But it is a signal that a manager who only looks at velocity will never see, and it is exactly the kind of information that is cheap to collect and expensive to guess at. The right use is the trend, not the snapshot: one busy weekend is a fact, four busy weekends in a row is a pattern, and the pattern is the conversation worth having, had with data instead of with hunches, before the hunches become resignations.
The takeaway
The ten are the ten, and the ten is the part the count promised. The entries are the working set, and the working-set is the part the reader keeps, because the keeps is the bookmark, and the bookmark is the part the list buys. gitpulse is Git analytics in your terminal: file hotspots, commit patterns, branch strategy, contributor impact., one command away with npx @wuchunjie/gitpulse, and the one-command is the part that makes the ten entries the ten commands instead of the ten readings. The repository is https://github.com/wuchunjie00/gitpulse, and the repository is the part the missing eleventh goes to, because the eleventh is the part the reader finds, and the finds is what the list that keeps working does.
Top comments (0)