Blog · GitHub
How many lines did I really change this week?
The raw sum of added and deleted lines from git measures the mass of data that changed, not the work done: without an exclusion rule, lockfiles, data files and build output count as much as code. In the calendar week from 22 to 28 September 2026 our total fell from +414,085 added lines to +89,450 once one fixed rule applied.
What do git’s insertions and deletions count?
Every line in every file a commit touches, whatever the file is. git log --numstat “shows number of added and deleted lines in decimal notation and pathname without abbreviation”; for binary files it “outputs two - instead of saying 0 0” (git manual, git log --help, git 2.54, checked 9 October 2026). A lockfile that a package manager rewrote and a hand-written function look the same in that output.
Which files distort the number?
Generated data, far more than lockfiles. In the calendar week from 22 to 28 September 2026 our 443 commits without merges added +444,132 lines. Lockfiles accounted for +30,047 of them; of the remaining +414,085, data files accounted for +324,635, about 78 percent, most of them JSON that one project regenerates from a source.
The week after, from 29 September to 5 October 2026, shows the other side: +63,504 lines without lockfiles, +54,418 after the rule. In a week without regenerated data the rule removes little, which is what it should do.
Which exclusion rule works?
One that removes files by their kind and catches single outliers. gitpuls uses this rule for every account it reads:
- JSON files except
package.json,tsconfig*.jsonandjsconfig*.json .geojson,.csv,.tsvand.xml- minified files, source maps,
.svg, snapshots and lockfiles - everything under
dist,build,vendor,node_modules,coverageand.next, at any depth - any single file with more than 3,000 changed lines in one commit
The last line is the safety net: it catches a generated file the patterns do not know yet. With the rule in place, the week from 22 to 28 September 2026 came to +89,450 and −27,565 lines.
To try it on your own repository, start with the lockfiles and data files and let git do the sum:
git log --since='1 week ago' --no-merges --pretty=tformat: --numstat -- . \
':(exclude)*.lock' ':(exclude)**/package-lock.json' ':(exclude)**/*.csv' ':(exclude)**/dist/**' \
| awk '$1 != "-" { add += $1; del += $2 } END { print "+" add, "-" del }'
Why not GitHub’s weekly code frequency?
Because it counts every file and stops at large repositories. GitHub describes the endpoint as “a weekly aggregate of the number of additions and deletions pushed to a repository” and adds: “This endpoint can only be used for repositories with fewer than 10,000 commits” (GitHub Docs, repository statistics, checked 9 October 2026). There is no way to exclude a file type, so the data files from above would be in it, and it shows one repository at a time, not a week across all of them.
How this text was written
This article was drafted with an AI assistant from our own measurements and the sources linked above, which were checked on 9 October 2026. The numbers come from the method page; nothing was estimated.